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Field of the Invention 

The invention relates top High Reliability systems for Real 
s Time Traffic, 

Background of the invention 

1. Separasjon kontroll og trafikk. 
a. SW I kontroll funksjon. 



b. SW upgrade. 
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c, Avbruddsfri SW upgrade. 



d. Selvtest uavhengig av trafikken 



e. Telecom Datasvits jer . 



Ny software inn I passiv bank. 
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Pass xv 



Summary Of the invention 1 Digital bilde 1. 

Oppgradering: I prinsippet ; peke pa Passiv og gj0re passiv 
aktiv og aktiv passiv. For dette kjores et testrun pa 
passiv, for blant annet a se at det ikke foreligger fatale 
feil ved oppgraderingssof twaren, som for eksempel kan fore 
til at en* mister kontakt med programmet . Ved test OK settes 
passiv bank lik aktiv bank. En kan selvfolgelig skifte 
dette tilbake nar som heist. 

En algoritme gj elder for aksept/ikke aksept av software: 
Sporsmal: Akseptere software? 

Ja; -Svitsje over manuelt, det vil si skifte aktiv og 
passiv bank manuelt. 

Ja; - svitsje over automat isk etter testrun. 

Ved ja pi sporsmalene foretas en svits j . laster kun 
ned nodvendige filer. _ , 

Konfigurasjonsfilhandtering se fcilde 2 dxgltalt kam&ra. 

Et poeng ved det distinkte skillet mellom traffic og 
control er at en da kan kj0re trafikk uavhengig av hva som 
skjer med control biten, dette er vesentlig for 
tilgjengelighet, upgrade, temper aturkont roll, service etc. 



Equipment 

control/ 

handling 



Control 



Traffic 



2 . Temperatur kontroll . 

a. Effekt kan reduseres ved at control funksjonen 
kan settes ut av drift, som folge av separasjonen 
vil dette ikke fere til endringer i 
traf ikksituas j onen . 

Normalt vil temperturkontrollen gi en hardware shutdown for 
a beskytte kortet mot skader, saledes vil en ikke fa 
forvarsler, en vil ogsa fa tap av tilgjengelighet uten at 
en mottar forvarsler. Prinsippet som anvendes i 
oppfinnelsen er et to trinnsprinsipp, en kunne tenkt seg 
flere trinn, men det har ingen hensikt-. . 
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Excessive area 




0 1 2 3 4 tid 

Om HTT = 1 then control = ut av drift 

Om HTT = 1 then send alarm til drift management systemet 
Om ETT = 1 then hardware shutdown, for a beskytte hardware 
mot brannskader. Alarm sendes drift management systemet. 

Syklus beskrivelse for figuren: 

0 --> 1 normal drift 

1 --> 2 kontroll funksjonene settes ut av drift 
automatisk, traffiken pavirkes ikke, grunnet separasjon, 
alarm sendes OAM. 

2 --> 3 Automat isk hardware shutdown, det vil si at 
traffikk og kontroll settes ut av drift, alarm til drift og 
management systemet. Systemet "sover" 

3 --> 4 Systemet starter . automat isk opp igjeh, men uten 
kontroll funksjoner status gj0res kjent for kontroll og 
management sys.temet . 

4 systemet gar automatisk tilbake til normal drift. 



Hensikten: 
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Excessive area 




0 1 2 3 4 tid 

Om HTT = 1 then control = ut ay drift 

Om HTT = 1 then send alarm til drift management systemet 
Om ETT =. 1 then hardware shutdown, for a beskytte hardware 
mot brannskader. Alarm sendes drift management systemet. 

Syklus beskrivelse for figuren: 

0 --> 1 normal drift 

1 --> 2 kontroll funks jonene settes ut av drift 
automat isk, traffiken pavirkes ikke, grunnet separasjon, 
alarm sendes OAM. 

2 --> 3 Automat isk hardware shutdown, det vil si at 
traffikk og kontroll settes ut av drift, alarm til drift og 
management systemet- Systemet "sover" 

3 4 systemet starter automat isk opp igjen, men uten 
kontroll funks j oner status gjores kjent for kontroll og 
management systemet. 

4 " r .-> Systemet gar automatisk tilbake til normal drift. 



Hensikten^ 



-kan arbeide ved hoyere omgivelsestemperatur 0kt 
kapasitet, redusert vif teavhengighet . 

- gir 0kt tilgjengelighet , idet trafikken ikke p&virkes av 
at kontroll funksjonaliteten koples ut. 

-genmerelt positivt med bedre. temeperaturs tyring, for 
holdbarhet , service etc 

Det anvendes redundante vif tesystemer , slik at eneste 
single point of failure finnes for vifte styringskortet I I 
Mer om det senere.-. . 



3. Tilgjengelighet/BPI bus 

General availability node/ protected interfaces, line 
protection interface. 

Tilgengelighet . 

MTBF: mean time between failure 
MiTR: mean time to repair 

Tilgjengelighet= MITR/MTBF 

Dersom NPU faller ut: (NPU Node Processing Unit) 
ingenting skjer med trafikken dersom ikke dette skjer 
ved MITR.l 

Uten separasjon sa vil kontrollsystemet p&virke 
tilgjengelighet. 

Med 155 Mbit/s inteface (selv. medtatt komponent aldring) 
„> 7000 kr tilgjengelighet (service medtatt) 



4. Skalerbarhet : 
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> Re ferer digitale bilder 

ASIC distribuert svitsjoing av porter. DFistribuerte 
syst enter skalerer godt nedover, men vanligvis ikke 
oppover . 

Skalerer godt, med fa kort .fordi senbtrale komaponenter 
ikke medtas, det vil si at nodeprisen for sma node blir 
lav, kun ta med NPU. 

A 

It is an object of the present invention to provide a 
method avoiding the above described problems. 

The features defined in the independent claims enclosed 
characterize this method. 

In particular, the present invention provides 
Brief Description of the drawings 

In order to make the invent ion. more readily understandable, 
the discussion. that follows will refer to. the accompanying 
drawing. 

Figure 1 Readers Guide documents for Traffic Node 

Figure 2 Application of the TN in the Lower Radio Access 
Network 

Figure 3 LRAN network and the role of various TRAFFIC NODE 

. sub -networks . 

Figure 4 O&M environment of Traffic Node 

Figure 5 The TN IP based DCN 



7 

Figure 6 TN modularity 
Figure 7 TN architecture 
Figure 8 TN software architecture 
Figure 9 TN BNH busses and building blocks 
s Figure 10 The TN AMM 2 Op Backplane 
Figure 11 TN BNS 

Figure 12 TN EEM: Framework and Basic Node 
Figure 13 TN BNH 

Figure 14 TN Application architecture 
io Figure 15 TN Application Software 
Figure 16 TN ANS architecture 
Figure 17 TN Application EEM 
Figure 18 TN Application Hardware 
Figure 19 TN APU 

is Figure 20 Example of a bi-directional 3*64Kbs cross- 
connection between the two APUs. 

Figure 21 PM handling in TN 

Figure 22 TN Alarm Handling overview 

Figure 23 El carried on one interface, 

.20 Figure 24 El carried on a terminal 
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Figure 25 Redundancy model - basis for calculations 
Figure 26 PIU function blocks 
Figure 27 ASIC block structure 
Figure 28 TDM bus redundancy : 

Figure 29 AMM 2 Op with redundant power distribution 
Figure 3 0 AMM 20p without redundant power distribution 
Figure 31 AMM 6p BN 

Figure 32 General model for protected interfaces 
Figure 33 Simplified model for protected interfaces 
Figure 34 General model - unprotected interfaces 
Figure 35 MCR 1+1 . \ 
Figure 36 MCR 1+0 
. Figure 37 MCR terminal 1+1 
Figure 38 MCR terminal 1+0 

Figure 38 STM-1 terminal 1+1 

Figure 3 9 STM-1 terminal 1+0 
* Figure 40 El terminal 1+1 

Figure 41 El terminal 1+0 (SNCP) 

Figure 43 Install new node 
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Figure 44 Repair NPU 

Figure 45 Change forgotten password 

Figure 46 Emergency fallback NPU 

Figure 47 Removal of board (for information only) 

5 Figure 48 Fault handling of hardware and software error. 

Figure 49 TN Handling of node error. 

Figure 50 TN Handling of APU/PIU errors. 

Figure 51 example of TN System Release structure 

Figure 52 Illustration of the various contents of the 
io APU/NPU memory banks 

Figure 53 The Software Upgrade process illustrated 
Figure 54 Su of a single APU due to a APU restart 
Figure 55 Hot Swap Software Upgrade 
Figure 56 TN reference network topology. 

15 Introduction 

Based on these principles the Traffic Node's architecture 
and functionality are described. The description is a 
principle/concept description which means that some things 
might be differently implemented in specific releases of 
20 the product ... 

The document provides an entry point into the TN system 
documentation and refers to the appropriate documents. 

Readers Guide 
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Figure 1 Readers Guide documents for Traffic Node 
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The Traffic Node and its environment 
The microwave network 

The TN is targeted to work in the PDH/SDH microwave 
transport network for the LRAN 2G and 3G mobile networks, 
5 as shown in Figure . 

Figure 2 Application of the TN in the Lower Radio Access Network 
End-to-end connectivity in the TRAFFIC NODE microwave 
network is based, on El network connections, i.e. 2Mbit/s. 
io These El network connections are transported over TRAFFIC 
NODE microwave links . The capacity of these microwave 
links can be the following: 

• 2 El, i.e. 2x2Mbit/s 

• lxE2, i.e. lx8Mbit/s 
is • 2xE2, i.e. 2x8Mbit/s 

• lxE3+lxEl, i.e. 34Mbit/s+2Mbit/s 

• lxSTM-1, i.e. 155Mbit/s 

Connectivity to/from the microwave network is provided 
through: 

• G.703 El interface 

• STM-1 interface. 

This is illustrated oii Figure 3. 

The microwave network consists of the following network 
elements : 

• TRAFFIC NODE E providing : 

• Medium Capacity Radio, 2x2-34+2Mbit/s 

• . PDH access on El f E2 and E3 levels 

• TRAFFIC NODE High Capacity providing: 

• High Capacity Radio, 155Mbit/s 

• optical/electrical STM-1 access 

• Traffic Node comprising: 

• El cross -connect 

• Generic network interfaces: 

• PDH access on El level 

• SDH access through optical/electrical STM-1 

• TRAFFIC NODE E compatible Medium Capacity Radio 
. • TRAFFIC NODE E co-siting solution 



30 
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Figure 3 ' L raN network and the role of various TRAFFIC NODE sub- 
networks . 

Figure 4 shows that Traffic node can be managed by: 

5 • A Local Craft Tool (EEM) , this is computer with a web 

browser that connects with the Embedded Element 
Manager (EEM) . 

• Remotely by .TRAFFIC NODE Manager, using a combination 
of both EEM and SNMP interface. 
io • Remotely by a operator specific Operations Support 

System (OSS) or Network Management System (NMS) . 



Figure 4 O&M environment of Traffic Node 

The DCN-IP network 1 
is In order to perform management of the TNs a Data 

Communications Network (DCN) is required. This is an IPv4 
based DCN that uses in-band capacity on the transport 
links by means of unnumbered PPP links. This requires a 
minimum of IP network planning and doesn't require 
configuration of the TN in order to connect to the DCN. 
OSPF is used as a routing protocol. Together an Ethernet - 
based site-L«AN connection to the TN, the TN DCN can be 
connected to any existing IP infrastructure as shown in 
figure 5. TN communicates with the following services: 



20 
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• DHCP, for assignment of IP addresses to equipment on 
the site -LAN, e.g. the EEM. The TN provides DHCP 
relay functionality for this. 

• NTP, the TN uses NTP for accurate time keeping 

• FTP, used for software upgrade and configuration up 
30 and download. 

• The Network Element Manager (NEM) uses SNMP for 
monitoring and configuring the TN. 

■V The EEM is a PC that communicates HTML pages 

containing JavaScript over HTTP with the Embedded 
35 Element Manager (EEM) in the . TN by means of a web 

browser. 



Figure 5 The TN IP based DCN 
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TN Principles 

This chapter describes the architecture of the TN, which 
consists of a Basic Node (BN) and Applications, and the 
principles on which it is based. Before looking at the 
architecture it self, the principles that for the basis for 
the architecture design are described below. 
Detailed description of the invention 



A first preferred embodiement of t he invention 
A second preferred em bodiem ent of t he invention 



Modularity 

The TN is based on a modular principle where HW and SW 
application can be added to the system through the use of 
uniform mechanisms. 

This allows for a flexible upgrade from both a HW and SW 
perspective, hence, new functionality can be added with 
minimal effort (at least from the end customer's point of 
with) . 

The TN Basic Node, TN BN, provides re-usable HW and SW 
components and services for use by application designers. 

Software of the TN BN and various applications, like MCR 
and STM-1, are integrated by the well defined interfaces. 
These interfaces are software function calls, file 
structures, hardware busses or common hardware and software 
building blocks. The well defined interfaces enable the 
application flexibility in design. As long as they conform 
to the interfaces there is a high level of freedom in how 
both software and hardware are implemented. 



Figure 6 TN modularity 
Scalability 

The principle of modularity and distribution of the system 
through the busses and their building blocks makes the 
system linearly scalable. 



.1 
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The distributed switching hardware architecture allows for 
the size of the node to scale from large node (20 APUs) 
down to small nodes (1 or 2 APUs) . 

The alternative centralised switching architecture allows 
for scaling up to higher capacity where the distributed 
architecture doesn't allow for capacity increase. 

Offering both a distributed switching architecture as well 
as being prepared for a centralised switching architecture 
enables scalability of traffic rates required today and in 
the future. 

Functional scalability is achieved through a distributed 
software architecture which allows for new functionality 
(applications) to be added trough well defined interfaces. 

Separated Control and Traffic systems 

A principle used to improve robustness is to separate the 
control and traffic system of the TN. The control system 
configures and monitors the traffic system. Whilst the 
traffic system routes the traffic through the TN. Failure 
and restarts of the control system will not influence the 
traffic system. 

Separation of control and traffic system applies throughout 
the node and its PIUs . 

This enables e.g. software upgrade of the TN without 
disturbing traffic. In the architecture description later 
it will be pointed out whether a component is part of the 
control or the traffic system. 

Redundancy 

A principle that provides robustness to the TN is x no 
single point of failure' in the traffic system. This means 
that traffic, is not disturbed as long as one failure occurs 
in the system. This is realised by redundant traffic * 
busses, optional redundant power and traffic protection 
mechanisms . More details on the redundancy of the various 
system components can be found in the following 
architecture sections. 

The architecture allows for application to implement . 
redundancy, like MSP 1+1 for the STM1- application or 1+1 
protection for the MCR link. 
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Tn service upgrade 

The principle of in-service upgrade, i.e. upgrade without 
disturbance of traffic, of both software and hardware 
functionality in the Traffic Node is applicable for: 

• Upgrade of all software in the Traffic Node to a new 
System Release 

• Hot -insert ion of PIUs, that are automatically upgraded 
to software matching the existing System Release of 
the Traffic Node. 

• Hot -swap of PIUs where a new PIU inherits the 
configuration of the old PIU. 

• 

APU handled by one Application 

Every APU in the traffic node handled by one application. 
One application can however handle several APUs, even of a 
different type. 

Future packet support 

For every new feature designed in the Traffic Node future, 
support for packet data, like ATM and IP, is taken into 
account . 

Use of industry standards 

The extensive use. of de-facto industry standards enables 
the use of third party products, competence acquisition, 
risk reduction and greater functionality differentiation. 



Functional distribution Basic Nod e versus Applications 

Some basic principles have been established in .traffic 
node when it comes to functional distribution between a 
common Basic Node and Applications. In this model 
applications are concerned with providing physical bearers 
. for end-to-end connections, i.e. physical and server layer 
links for PDH traffic. This entails: 

• Line interfaces 

• Server layer multiplexing (everything * below' PDH) 

• Fault propagation (on link level) 

• Physical line protection 

• Physical line diagnostics like loops and BERT 

• Peripheral equipment handling, e.g. RAU. 
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Whereas Basic Node provides: 

• Generic/ standard network interfaces 

• PDH Networking 

• PDH multiplexing 

5 • Fault Propagation (network level) 

• Cross-connection 

• Network protection, i.e. SNCP 

• Network layer diagnostics like" loops and BERT 

• DCN handling, i.e. IP and it's services like routing, 
o FTP etc. 

• Equipment Handling on node and PIU levels 

• Maintaining consistent configuration of the node, e.g. 
a System Release. 

• Means to an application to communicate with /control 
L5 its APUs. 

« 

TN Architecture 

Figure 7 shows a complete overview of the TN architecture. 
In a TN there will be one component called TN BN and 
several different instances of the TN Application 
20 component. Both kind components can consist of both 
hardware and software. 

The next sections will first look at the overall software 
and hardware architecture of the TN. Afterwards the basic 
node architecture and application architecture will be 
25 described more detailed. 



7 TN architecture 

TN Software Architecture 

The TN software consists of three major software component 
types: 

• Basic Node Software (BNS) 

• Application Node processor Software (ANS 

• Application Device Processor Software (ADS) . 

As shown in Figure 7, TN BNS and the various applications 
communicate through the Basic Node Functions (BNF) 
interface. This interface consists of two protocols: 

• AgentX that together with its SNMP master and SNMP. 
sub-agents acts as a object request broker used to 
realise an extensible SNMP agent. The SNMP sub-agents 
subscribe with the SNMP-master in the BNS to receive 
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the SNMP requests that the applications wants to 
handle. The SNMP master in its turn acts as a post- 
master that routes SNMP requests to the SNMP sub- 
agents in the applications. 

• CLI based on the same principles as AgentX but then 
for the CLI protocol. This interface is used for CLI 
requests, collection of configuration data for 
persistent storage and configuration at start-up. 

• Basic Node Functions (BNF) signals, a proprietary- 
message interface for inter-process communication. 

Both protocol peers on the application side are contained 
in the Application Interface Module (AIM) as shown in figure 
8. 



FignHre 8 TN software architecture 



TN Hardware Architecture 

The Traffic Node's hardware architecture consists of Basic 
Node Hardware (BNH) in which Application Plug- in-Units 
(APU) can be placed. The BNH provides various communication 
busses and a power, distribution bus between the various 
PIUs in the TN. The busses them selves are part of the 
backplane, i.e. TN BN, whilst PIUs interface to' these 
busses through . TN BNH Building Block (BB) is shown in 
figure 9. 

Figure 9 TN BNH busses and building blocks 

As an illustrative example figure 10 shows the busses and 
their location on the AMM 20p backplane. ." 



Figiare 10 The . TN AMM 2 Op Backplane 

In the next sections these busses and their corresponding 
building blocks will be discussed. 

SPI Bus 

SPI is a low speed synchronous serial interface used for 
35 . equipment handling and control of : 

• APU cold and warm resets 

• status LEDs and BRS 
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• Inventory data, like product number, serial number, 
asset identifier etc. 

• Temperature supervision 

• Power supervision 

• BPI disable/enable 

• PCI fault handling 

• General purpose portsThe SPI BB is implemented in a 
Complex Programmable Logic Device (CPLD) .The SPI bus and 
BBs are part of TN's control system. 

PCI Bus 

The PCI bus is a multiplexed address/data bus for high 
bandwidth applications and is the main control and 
management bus in the TN-Node. Its main use is 
communication between NP Software (NPS) and Application DP 
Software (ADS) , TDM BB and ASH like Line Interface Units 

(LIU) . The PCI bus is part of the control system. The PCI 
BB is implemented in a Field Programmable Gate Array 

(FPGA) . 

TDM Bus 

The TDM bus implements the cross-connects functionality in 
the TN. Its BB is implemented in an Application Specific 
Integrated Circuit (ASIC). Characteristics are: 

• 32 port per ASIC, where each port can have a capacity 
of 8kBit/s to 45MBit/s 

• The bus with TDM BBs provide a non-blocking switching 
capacity of -400 El ports (800Mbit/s) , i.e. 200 bi- 
directional cross -connect s . 

• Redundant switching function 

• Cross connection 

• Routing DCN to the IP router on the NPU. 

• Support for PDK synchronization hierarchy. 

TDM bus and its BBs are part of the traffic system. 
Power 

Power distribution, optional redundant (have to install two. 
PFUs) as being part of the traffic system. DC/DC conversion 
is distributed and present at every PIU. 

Synchronisation busses 

The PDH synchronisation bus provides propagation of 
synchronisation clock between PIUs as well distributes the 
local clock. 
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The SDH synchronisation bus provides propagation of 
synchronisation clock between PIUs. 

Being part of the traffic system, .both PDH and SDH 
synchronisation busses are redundant. 

BPI busses 

BPI-2 and BPI-4 can be used for application specific inter- 
APU communication. The communicating APUs must then be 
located in the same group of 2 respectively 4 slots, i.e. 
located in specific neighbouring slots in the TN rack. The 
BPI busses are controlled by the application. 

Point -to- Point bus 

The Point -to- Point (PtP) bus is meant for future central 
switching of high-capacity traffic. 

Programming bus 

The programming bus is intended as JTAG bus for programming 
the FPGAs in the node. 

Basic Node Architecture 

The TN BN consists in the TN product structure of two 
components : 

• TN BNS, TN Basic Node Software 

• TN BNH, TN Basic Node Hardware 

Although the TN EEM is not a part of the TN BN in the 
product structure, in practice it is a necessary part when 
building TN Applications that need to be managed by the 
EEM. That is why in the rest of this document the TN EEM is 
regarded as a part of TN BN. 

These three TN BN components will interface to their peer 
components in the TN Application through well defined 
interfaces. 

TN Basic Node Software 

The TN BNS realises control and management of the TN BN 
and its TN BNH BB that reside on the various APUs. 
Therefore it is part of . TN's control system, and delivers 
its services to the TN Applications. It is part of the TN 
control system and not of the traffic system. 



The main Basic Node architectural concept is its 
distributed nature. For the SNMP and CLI interfaces there 
is a Master/Sub-Agent architecture, where the master acts 
as a postmaster and routes requests to the sub-agents as 
shown in figure 8. Each sub-agent handles its part of the 
SNMP object tree or it sub- set of the CLI commando's. 



Figure 11 TN BNS 

TN BNS External Interfaces 
The TN BNS provides the following external interfaces : 

• HTML/HTTPS, the embedded manager, TN EEM, sends HTML 
pages to a browser on the operator's computer. HTTPS is 
used to provide encryption especially on the username and 
password of the HT pages. 

• DCN Services, various IP protocols such as: 

• DNS 

• NTP for synchronisation of the real-time clock 

• FTP for software upgrade and configuration up/download 

• Telnet for CLI configuration 

• DHCP for TN acting as an DHCP relay agent 

• CLI , over Telnet, limited configuration of the TN 
through Cisco alike commands. 

• SNMP,. O&M interface using SNMPv3 to configure the 
node, gets it status and send traps to the manager. 
Configuration by means of SNMPvl/v2 is optional. 

TN Embedded Element Manager 

The TN can be managed through either the SNMP interface or 
a WEB. based embedded manager . This embedded manager 
consists of two parts: . . 

A WEB- server located in the TN BNS able to execute 
PHP script 

• HT pages with embedded PHP script, denoted as TN EEM. 
These pages can be divided into three categories : 

• Framework, generic pieces of HTML/PHP code part of the 
TN BN 

• Basic Node management, part of TN BN 

• Application management, AWEB, part of the TN 
application 
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Figure 12 TN EEM: Framework and Basic Node 

The WEB server receives an URL from the EEM and retrieves 
the. page. Before sending the page to the EEM it interprets 
5 the PHP code, which is replaced with the return values of 
the PHP call. The WEB-server interfaces to the SNMP-master 
in the TN BNS by executing the PHP SNMP function calls. 
The TN EEM is part of the TN control system. 

As described above interfaces the TN EEM to the WEB-server 
io in the TN BNS through HTML with embedded PHP script. 

TN Basic Node Hardware 

Figure 13 TN BNH 

The TN BNH consists of: 

is • TN BN backplane providing the previously described 

busses 

• Building blocks that enable APUs to interface these 
busses : 

• SPI 
20 • PCI 

• Power 

• TDM 

• TN BN PIUS: 

• NPU, Node Processor unit running TN BNS and ANS . The 
25 NPU also provides : 

• 8 El Traffic Interfaces 

• V.24 interface 

• Ethernet interface 

• 3 digital input and outputs 

so e pfu, Power Filter Unit, providing power to the other 
PIUs. 
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• FAU, although not a real PIU in the sense that it is 
not couple directly to the busses in the backplane. 

• TN BN Mechanics: 

• Rack, providing space to 2 0 or 6 large format PIUs 
(i.e. excluding PFUs and FAU) 

Interface towards • TN BNS 

The BNS-BNH interface is register and interrupt based. 
A pplication Architecture 

Figure 14 shows the internal components of an TN 
Application that will be discussed in the following 
sections: 

• TN EEM: AWEB, application specific HTML /PHP pages for 
management of the application 

• ANS, Application Node Software is the software needed 
for the application running on the NPU, i.e. on Linux OS. 

• ADS Application Device Software, is the software 
running on the processor on the APU, in case a processor is 
present . 

• APU, Application Plug-in Unit/ is the application 
board. 



Figure 14 TN Application architecture 
TN Application software (ANS+ADS) 



Figure 15 TN Application Software 

The application software consists of: 

• ANS running on the NP (see also figure 15). on the NPU. 
This software is running even if the corresponding APUs are 
not present in the TN. It is the control software for the 
application and as for all software on the NPU, failure 
will not cause traffic disturbance . 

• ADS is located on the APU if the APU houses one or 
more processors. 
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Figure 16 shows the internal ANS architecture, where the 
AIM, Application Interface Management module, houses SNMP 
and CLI sub-agents that are responsible for the application 
specific SNMP objects/CLI commands. 

The ADD, Application Device Driver, contains application 
specific device drivers and real-time ANS functions. 

The architecture of the ADS is very application specific 
and interface only to the ANS and not to any part of the TN 
BNS directly. 



Figure 16 TN ANS architecture 
Interface towards BNS 

The BNF, Basic Node Function, provides the interface 
between ANS and BNS. It comprises of 3 sub-interf aces : 

• CLI, protocol for the AIM for CLI sub-agent to CLI- 
master communications. Used for e.g. persistent 
configuration storage. 

• AgentX, protocol for the AIM for SNMP sub- agent to 
SNMP master communications. Used for SNMP configuration and 
alarms etc. 

• BNF Signals for message based communication between 
AIM and BNS . This can in principle also be used between 
other processes. 

TN Application EEM 

The application specific WEB pages are located on the NPU. 
These pages contain HTML and PHP script that is executed by 
the WEB -server in the TN BNS. The WEB-server executes the 
PHP. SNMP function calls and talks to the SNMP master, which 
its turn delegates the request to the SNMP sub-agent 
residing in the AIM of the respective ANS. 



Figure 17 TN .Application EEM 
Interface towards TN EEM 

The AWEB interfaces to the rest of the TN EEM through a 
naming convention for the respective HTML/PHP files . 
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TN Application hardware 

The hardware of the application is called an APU, 
Application Plug-in Unit. The application specific hardware 
uses the TN BNH BBs , to interface to the TN BNH and so to 
the. other PIUs in the TN as shown in figure 18. 

Figure 18 TN Application Hardware * 

Figure 19 shows how and APU is build-up from Application 
Specific Hardware (ASH) and the TN BNH BBs. 



Figure 19 TN APU 

Mechanically the APU interfaces with the TN BNH rack and 
backplane . 



TN Functionality 

In this section the TN functionality as described in the 
various Functional Specifications is mapped onto the 
architecture described previously. 

Equipment Handling 

Equipment comprises of: 

Installation and repair 
Restart 
, Supervision 
Inventory and status 
Node Configuration Handling 

Inventory and status. 

The SPI bus is used to scan the TN for PIUs, Hardware 
inventory data of these PIUs is retrieved from the SPI BB 
by the TN BNS EHM, through a SPI device driver. Thxs data 
is represented in both, the ENTITY -MIB as well as the TN- 
MODULE-MIB handled by the EHM. 

Inventory data on the software on the various APUs is 
handled by the corresponding ANS that holds its part of 
inventory table in the TN- SOFTWARE -MIB . 
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Equipment status on the TN and PIUs is partly controlled 
through the SPI BB for faults like high temperature, 
restart and board type* Other possible faults on equipment 
are communicated from ANS to EHM in the BNS . These faults 
will often be communicated over PCI from an ADS to its ANS - 

Equipment Installation and Repair 

Installation of a new TN is regarded as part of equipment 
handling, but is ' actually a set of sub- functionalities like 
DCN configuration,, software upgrade password setting (SNMP 
Module) and configuration download under direction of the 
Equipment Module. 

Hot -swap is supported to enable plug & play on all PIUs 
except NPU. It uses both SPI and PCI busses and is the 
responsibility of the Equipment Module in the BNS. Plug & 
play for PIUs that' have to be repaired is realised by 
saving the PIUs configuration for x 6 minutes period after 
it has been removed. A new PIU of the same type can then 
inherit this configuration when inserted within x 6 minutes 
after removal. 

Restarts 

The node and APUs can be cold and warm restarted as a 
consequence of external management requests or 
software/hardware errors. Warm restarts will only affect 
the control system whilst a cold restart also affects the 
traffic system. Cold and warm restarts of APU is 
communicated using the SPI. 

Node configuration persistence 

Running configuration is stored persistent in the TN's 
start-up configuration file in flash memory. The CLI master 
in the TN BNS invites all TN BNS modules and the AIMs in 
the ANS to submit their running configuration to the start- 
up configuration file. 

Saving the running configuration will also lead to saving 
the new start-up configuration file to an FTP server using 
the FTP client in the TN BNS. 

Supervision 

The following sub-systems are supervised for. 
software /hardware errors: 

• NPU Processes by a watchdog reporting errors in an 
error log available to management. 

• ANS supervision; 



• * the Equipment Module will poll the AIM to check 
whether is alive, using a BNF call 

• the AIM monitors it's ANS internal processes 

• the ANS is responsible for supervision of the ADS 
processes and DP-NP communication links (SPI & PCI) 

• PCI bus 

• SPI bus 

• APU supervision of power and temperature is supervised 
by the BNS using the SPI. 

• FAN Supervision through SPI by the BNS . 

Detection of errors will in most cases lead to a restart or 
reset of the failing entity as a identification and repair 
mechanism. 

Traffic Handling 

Traffic handling functionality deals with traffic handling 
services offered by the TN BN to the TN Applications. The 
following sections describe sub-functions of traffic 
handling. 

Cross connect . 

Cross-connections between interfaces, offered by 
applications to the TN BN, are realised in . TN BNH by the 
TDM bus and the TDM BBs, under software control by the 
traffic handler in the TN BNS . Applications register their 
TDM ports indicating the speed. After this TN BN can 
provide cross-connections with independent timing of the 
registered ports. 

Bit pipes offered by applications on TDM ports are chopped 
in 64Kbps timeslots which are send on the TDM bus and 
received by another TDM BB on the bus and compiled into the 
original bit-pipe. Figure 20 shows and example of a cross- 
connection. 

Figure 20 Example of a bi-directional 3*64Kbs cross- 
connection between the two APUs 
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Sub-Network Connection Protection 

SNCP provides 1+1 protection of connections in the network, 
offered by the TN Applications on TDM ports, over sub- 
networks. Outgoing traffic is transmitted in two different 
directions, i.e. TDM ports, and received from one of these 
directions. Faults detected on the receiving line cause the 
TN BNS to switch to the TDM port from the other direction. 

As with cross-connections, SNCP is implemented in TN BNH by 
the TDM bus and TDM BBs . TN BNS traffic handler controls 
management of the SNCPs. 

Main characteristics of the SNCP: 

• permanently bridged 

• unidirectional switched 

• non- revert ive 

• requires no extra capacity on the TDM bus 

• part of control system. 

Equipment protection 

Equipment protection is provided by TN BN in the form of 
the TDM bus, the TDM BBs and BNS. It provides protection 
between two APUs based on equipment failures. An 
application can order this service between to APUs from 
BNS. BNS will then set-up the TDM BBs on both APUs and 
switch from one TDM BB to the other upon an equipment 
failure . 

Performance Management 

BNS, and more precise the ASIC DD, collects performance 
report on TDM ports every x x second , from either the TN 
Application, the. ADD in the ANS, or from the TDM BB. This 
data is reported further to the Performance management in 
the traffic module of TN BNS. Here the TN BNS offers the 
service to update current and history performance records 
of the TDM port based on the x x reports. These performance 
records are available to the ANS to be presented to 
management in an application specific SNMP MIB. 

To have synchronised PM intervals applications will collect 
their application specific PM data based on the same Ti 
signal as the BNS. 

The TN BNS, or more specific the traffic module, also keeps 
track of performance threshold crossings in case of TDM 
BBs . 
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All communication between the BNS and ANS uses BNF 
messages . 

Figure 21 PM handling in TN 
Connection Testing 

For testing purposes the TN BNS provides a BERT service to 
applications. Where a PRBS can be sent on one port per ASIC 
per APU concurrently and a BER measurement is performed in 
the receiving direction. 

For protected connections, i.e. SNCPs, one BERT s provided 
per node. 

The TN BNS also realises connections loops on the TDM bus 
by programming the ' TDM BB to receive the same time- slot as 
transmitted. 

On the physical transmission layers line and local (or 
inward) loops can be used in the fault location process. 

Alarm Handling 

Defects in the TN, that need to be communicated over the 
SNMP interface to a manager, are detected by the 
corresponding resource handler. The resource handler, e.g. 
an ANS or BNS process, . will be first informed about the 
defect through SPI or an ADD that reports over PCI. The 
defect will be reflected in the SNMP status objects hold by 
the ANS. 

Alarm suppression is performed in the TN in order to 
prevent alarm storms and simplify fault location. For this 
purpose defects for various sources are correlated. An 
application can do this for its own defects but can also 
forward a defect indication to the BNS in order to suppress 
BNS alarms. A general rule is that equipment alarms 
suppress signal failure a:larms who in their turn suppress 
performance alarms. Also lower layer (closer to the 
physical layer) alarms will suppress higher layer alarms . 

Using the AgentX interface the AIM will report an alarm 
for the defect to the Alarm handler functionality in the 
SNMP module in the BNS. Alarms will be stored in: a current 
alarm list and a notification log. It is then up to the 
manager to subscribe on these notifications that are sent a 
SNMP traps in IRP format . 
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Figure 22 TN Alarm Handling overview 
Software Upgrade 

The software upgrade functionality allows the operator to 
download a new System Release, that consists of a NPU Load 
module and several DP load modules, on a node per node 
basis . Topology and available DCN. bandwidth may allow for 
several nodes to be upgraded concurrently. However, which 
upgrade strategy is used is up to the NMS. 

The TN BNS upgrades its self plus all ANS. The ANS are 
responsible for upgrading the corresponding DPs using the 
TN BNS's FTP client and RAM disk as temporary storage 
medium before transporting the load module to all the APUs 
over PCI to be stored into the APU passive flash memory. 
This happens while the software in the active flash memory 
is executed. 

The software upgrade process is fail-safe in that respect 
that after a software upgrade the operator has to commit 
the new software after a test run. If a commit is not 
received by the node, it will fall back to the old 
software. It is also possible to have the node self 
execute a rudimentary test without the need for the 
operator to commit . 
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TN: Availabillity models and calculations 



Abstract 

This document describes the availability models that serve 
as the basis for the design of the TN. It also includes the 
calculated failure rates and MTBR figures for the TN. 

Prerequisites 

The reliability calculation for the TN connections are 
based on the following prerequisites: 

Calculation method 

All calculations are based on MIL-HDBK-217F Notice 1 with 
correction factors. The correction factor is based on 
actual experience data and compensates for the difference 
in use of a commercial and a military system. A milxtary 
system is normally used for a short interval with long 
periods of storage whereas a commercial system is xn 
constant use. 

El connection 

The connections are bi-directional connections on one 
interface type. 

Figure 23 El carried on one interface. 
For terminals the picture below applies . . 



Figure 24 El carried on a terminal 
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Redundancy Model 

The calculations are based on the general model. With fault 
detection in the control parts, with X, R = X 3 , Hr = = Vc (p. 
- i/MTTR) . Generally Hu can be expected to be shorter as a 
service affecting failure will be raised as a major or 
critical alarm. 

U - (2A. T + X c + 6hrX c /[i) Wn 2 , -and as: x = U*u,X = (2*, + Xc + 



Figure 25 Redundancy model - basis for calculations 
MTTR 

MTTR = 24h , (H = |iu = He = l/MTTR = 1/24) This is a 
simplification as the traps indicating faults are divxded 
into the categories: warning, minor, major and critical. 
The simplified meanings of these severities are: 
information, control function failure, loss of redundancy 
and loss of traffic. It is reasonable to expect a short 
MTTR to a critical alarm whereas a warning or minor may 
have a longer MTTR. Still 24h is used as a common repair 
time: 

Temperature 

The calculations are related to a 40 °C ambient component 
temperature. The TN-E estimates are all done at 40 C and 
the correction factor may include temperature compensation 
if the actual temperature is different from this. Therefore 
the TN estimates are set at the same temperature. The 
correction of the temperature at some units is related to 
the specific cases where the units are consuming little 
power and thus have a relative temperature difference wxth 
respect to the other units. 
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PIU function blocks 

All PIUs are divided into three parts. Control, traffic and 
parts common to both. This gives the following simple model 
for the traffic and control function availability: 



Figure 26 PIU function blocks 

The control part is any component whose failure does not 
affect the traffic. The traffic part is components whose 
failure only affects the traffic. The common part is 
components that may affect both the traffic and the 
control. Some examples: 

• Traffic: ASIC, BPI, Ella, interfaces, muxes 

• Control: PCI, DP, SPI EBPROM 

• Common, Power, SPI CPLD, SPI temp sensor 

The control block and the traffic block are repaired 
individually through separate restarts. 
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The General TN availability models 
Basic node availability models 
Cross connect 

The cross-connect function in the TN is distributed and is 
implemented though the ASIC circuits. 

The failure rate, of an El connection through the ASIC is 
not the same as the MTBF of the circuit. The ASIC is 
divided into a port dependant part and the redundant cross- 
connect. The failure rate of one port (including 
scheduler) is 20% of the ASIC MTBF and the TDM bus (cross- 
connect) is 30% of the ASIC MTBF. 



Figure 27 ASIC block structure 

The model for the redundant cross -connect can be seen 
below: 



Figure 28 TDM bus redundancy 

From the following can bee seen: 

Upross connect - (2XroM+Xpci + NPa-C+6X TDM Xpci + NPO-c/p) Xtdm/P 

As can be seen the TDM bus redundancy improves the failure 
rate by a factor of more than 50000. This makes the TDM bus 
interface insignificant and it is therefore omitted from 
the calculations. The ASIC contribution to the El failure 
rate is then 20% of the ASIC MTBF. This contribution is the 
port reference in the general availability model. 
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AMM 20p 

The AMM 2 op can be equipped with or without redundant PFUs. 
The two models for this are shown below: 



Figure 29 AMM 2 Op with redundant power distribution 

Figure 30 AMM 2 Op without redundant power distribution 

The fan (FAU1) consists of one fan control board (FCB) and 
3 fans. If one of the 3 fans fail a notification will be 
sent and the two remaining fans will maintain cooling in 
the repair interval. The FCB powers all 3 fans and is 
therefore a common- dependency-. 

The power distribution in the AMM20p is redundant but the 
node may be equipped without redundant PFUs if so desired. 
The power distribution has a very high reliability even 
without the redundancy. This option is therefore generally 
viewed as a protection against failure of the external 
power supply rather than the node power distribution. 

There is no dependency to a control function for the 
switchover between the redundant parts for the power or the 
fans. 

The unavailability in a 2 of 3 system is given by the 
equation: 

U 2 / 3 - Ui 2 (3 - 2Ui) where Ui is the unavailability of one 
branch. 

The Power distribution when redundant is a 1 of 2 system. 
The unavailability of this is given by the equation: U i/ 2 - 

AMM6p 

The model for the AMM 6p is shown below: 



Figure 31 AMM 6p BN 

The fan (FAU2) consists of one PCB with 2 fans. If one of 
the 2 fans fail a notification will be sent and the 
remaining fan shall maintain cooling in the repair 
interval. There is no dependency to a control, function for 
the switchover between the redundant parts for the fans. 

The fan is thus a 1 of 2 system. The unavailability of this 
is given by the equation: U i/ 2 = ^i 2 

General availability model - pr otected interfaces 



Figure 32 General model for protected interfaces 
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This model is the basis for the design of protected 
interfaces in the TN node. 

The level of redundancy in the basic node depends on the 
type of basic node. The cross-connect is redundant. This is 
always in operation and may not be turned off. 

The line and equipment protection schemes vary from 
application to application. Generally the line protection 
is much quicker and is intended to maintain connectivity 
during line faults. The requirement is therefore that the 
traf fical disruption as a consequence of line faults shall 
be less than t 4 msec. The equipment protection is allowed 
to be slower (x 5 sec.) as the MTBF of the protected parts 
are much better. Note that the line protection will repair 
many equipment faults as well. 

Simpli fied model - protected interfaces 

The figure below shows a simplified model, which is used 
for the calulations. 



Figure 33 Simplified model for protected interfaces 

i 

This model is used as the basis for "the actual calculations 
a ? t ^ ie se P aration of the blocks in tAe general model may be 
difficult. As an example of this consider a board that has 
the SDH multiplexers and the SOU termination in the same 
circuit. The line protection and the equipment protection 
availability are difficult to calculate* as the circuits 
combine the functions. This is the case even though the 
implementation clearly separated. 

This model will not provide as good results as the more 
correct general model since the simplification views the 
protection mechanisms as two equipment protected PIUs 
without the line protection 

The redundant cross-connect is omitted from the. 
calculations. The APU port is 20% of the ASIC -s.ee chapter 
0. The traffic functions of an APU is then used with 2 0% of 
the ASIC as the basis for the calculations. 

From the following can bee seen: 

Ui+i = Xbn-t /p + (2^aot-T:1+X + A, {A p U+NPU) _ c + S^apu^. (apu+NPU) - 

c/jJ*) ^-APU-T:l+l/H 2 
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General availability model - unprotected interfaces 

The figure below shows the model for unprotected 
interfaces : 



s Figure 34 General model - unprotected interfaces 

This model is the series connection of the Basic Node and 
the traffic part of an APU. 

Note that for unprotected interfaces the Basic Node is 
assumed to have non- redundant power. 

10 MCR availability 

Prerequisites . 

• The MMU2 MTBF calculation is divided not only with 
respect to control and traffic but also with respect to the 
use of the PIU. When the unit is used in a 1+1 

15 . configuration the ASIC and. Ella are not in use. Faults will 
then not be discovered in these components and the 
components are therefore not included in the calculation. 

• The SMU2 MTBF calculation is divided not only with 
respect to control and traffic but also with respect to the 

20 use of the PIU. When the SMU2 is used as a protection unit 
then the line interfaces are not in use. Faults will then 
not be discovered in these components and the components 
are therefore not included in the calculation. 

• The calculations can be seen in chapter Feil I Fant 
25 ikke ref eransekilden. . / 
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MCR: 1+1 interface 



Figure 35 MCR 1+1 
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MCR: 1+0 interface 



Figure 36 MCR 1+0 
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MCR; 1+1 terminal 

Figure 37 MCR terminal 1+1 

MCR; 1+0 terminal 

Figure 38 MCR terminal 1+0 
STM-1 availability 
Prerequisites 

• The STM-1 models are the same as the generic TN 

models. They are therefore not repeated here. 

STM-1; 1+1 Terminal (MSP1+1) 
Figure 39 STM-1 terminal 1+1 

STM-1; 1+0 Terminal 

Figure 40 STM-1 terminal 1+0 

. liTU 16X2 availability , 
Prerequisites 

• The LTU 16x2 models are the same as the generic 

TN models. They are therefore not repeated here. 

El terminal 1+1 (SNCP) 



Figure 41 El terminal 1+1 



El terminal 1+0 
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Figure 42 El terminal 1+0 (SNCP) 

Results and discussion 
5 The calculated results can be seen in the table below. 





AMM20p 


AMM6p 


Requirement 


MTBF for interfaces: 


MTBF (y/f) 


MTBF (y/f) 


MTBF (y/f) 


Unprotected radio 
interface 


71 


74 


- 


Protected radio 
interface * 


256 


232 


- 


Unprotected STM-1 
interface 


186 


206 




Protected STM-l 
interface * 


7121 


1811 




Unprotected El 
interface . 


227 


258 




SNCP protected El 
interface * 


7128 


1812 





MTBF for terminals: 


MTBF (y/f) 


MTBF (y/f) 


MTBF (y/f) 


Unprotected radio 
terminal 


58 


59 


59 



40 



Protected radio 
terminal * 


138 


131 


250 


Unprotected STM-1 
terminal 


115 


122 


100 


Protected STM-1 
terminal * 


288 


258 


250 


Unprotected El 
terminal 


129 


139 


100 


SNCP protected El 
terminal * 


288 


258 


250 



Mean Time Between 
Repairs for: 


MTBR (y/r) 


MTBR (y/r) 


MTBR (y/r) 


Unprotected radio 
terminal 


35 


40 


59 


Protected radio 
terminal * 


19 


21 


27 


Unprotected STM-1 
terminal 


40 


48 


100 


Protected STM-1 
terminal * 


26 


31 


50 


Unprotected El 
terminal 


53 


67 


100 


SNCP protected El 


3*7 


5C 


1 50 
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terminal * 



Availabillity for 
terminals: 








Unprotected radio 
terminal 


9,999524E-01 


9, 999538E-01 


- 


Protected radio 
terminal * 


9,999802E-01 


9,999790E-01 


- 


Unprotected STM-1 
terminal 


9,999762E-01 


9,999776E-01 


- 


Protected STM-1 
terminal * 


9,999905E-01 


9,999894E-01 




Unprotected El 
terminal 


9,999788E-01 


9, 999802E-01 




SNCP protected El 
terminal * 


9,999905E-01 


9,999894E-01 





Table 1: Summary of failure rates (*AMM20p with protected 
PFU1) 



The radio- terminal availability may be improved by changing 
the way the Els on the LTU 16x2 are handled. In TN a 
failure of one interface will result in the restarting of a 
complete board. This means that from availability point of 
view the system punishes boards with many interfaces per 
unit. If the fault handling procedure is changed so that a 
fault on one interface only results in a restart of that 
interface then the LTU 16x2 will improve its failure rate 
by a factor of 3 . This will give the following results for 
the terminals: 
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MTBF for terminals: 


MTBF 

(y/f) 


MTBF 

(y/f) 


MTBF 

(y/f) 


Unprotected radio 
terminal 


66 


68 


59 


Protected radio terminal 
* 


199 


184 


250 


Unprotected STM-1 
terminal 


154 


168 


100 


Protected STM-1 terminal 
* 


800 


602 


250 


Unprotected El terminal 


303 


361 


100 


SNCP protected El 
terminal * 


80C 


) 602 


> 250 



Table 2 : Improvment by changing the El fault handling 

The calculations are based on the use of the LTU 16x2 for 
the terminal. For some cases it may be possible to use the 
local drop on the NPU 8x2 instead. If this is done then the 
5 results are as shown below: 



MTBF for terminals: 


MTBF 

(y/f) 


MTBF 

. (y/f) 


MTBF 

. (y/f) 


Unprotected radio 
terminal 


63 


65 


59 


Protected radio terminal 
* 


171 


160 


250 


Unprotected STM-1 


137 


148 


100 
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terminal 








Protected STM-1 terminal 
* 


484 


403 


250 


Unprotected El terminal 


O f. 1 
Z U J 




100 

■la V \S 


SNCP protected El 
terminal * 


484 


403 


250 



Table 3 : NPU 8x2 used as terminal interface . 



Notation 

The symbol notation failure rates . for PIUs is: X <un i t /function>- 

<T/C> : <operational mode> Where: 

unit/function is the PlU/function name e.g. MMU2, MCR or 
MCRTer 

- T/C = Traffic/control. 

- operational mode , is usage, e.g. 1+1 or 1+0. 
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TN: EQUIPMENT HANDLING 



Abstract 

This document describes hardware and software equipment 
handling in the TNI Examples of this functionality are: 

• Equipment start/restart 

• Equipment supervision and redundancy 

• Equipment installation, upgrade and repair 

• Inventory management 



The scope of the document is to specify the equipment 
handling functionality of the TN on system level. The 
functionality will be further detailed in Functional 
Descriptions (FD) , Interworking descriptions (IWD) and 
design rules (DR) . 

IMPROVEMENTS 

The following is a list of possible improvements for the 
future: 

• . The APUs should possibly have the yellow LED on if the 
PCI bus is unconfigured. This would indicate to the service 
personnel that for reset, restarting or absent NPUs the 
APUs may be removed. 

• Chapter describing management view including entity 
MIB . 

Principles regarding PIU, FAU, RAU should be included. 

• PtP BPI handling has to be described. 
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PRINCIPLES 

The TN equipment handling is based on a few important 
principles : 

Redundant traffical system 

The traffical system is required to be configurable as 
redundant. It shall withstand one failure. It is assumed 
that the failure will be corrected before a second failure 
occurs. The fault identification is therefore required to 
be extensive. If a fault cannot be discovered it cannot be 
corrected . 

This requirement makes it necessary to have redundant ATM 
switch and IP router slots in the subrack. 

Separated control and management system 

The system is required to have the control system separated 
from the traffical system. The reason for this is that: 

• The control system can be non-redundant . A failure in 
the control system will not influence the network 
connectivity. This greatly reduces cost and complexity. 

• It simplifies in service upgrade. The control system 
can be taken out of service to be upgraded without any 
traffical impact . 

• It enables extensive self -tests. The control system 
may be reset and any kind of self -test (within the control 
system) may be performed. This allows for self -test that 
have a high likelihood of providing a correct fault 
localisation to be executed. 

In service upgrade 

The system shall be in service upgradeable. This means that 
without disturbing the established traffic it shall be 
possible to: 

• Perform SW upgrade. 

• Add new PIUs (requires hot swap for all but NPU) . 

• Remove/replace any replaceable unit (requires hot 
swap) . If an APU is protected then the operation shall give 
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less than x 4 msec, disturbance on the connections on that 
board. The operation shall not give any disturbance on any 
other connections. 

NPU redundancy 

The TN has a requirement to be prepared for NPU redundancy. 
This is to allow for: 

• Higher control system availability. A failure in the 
control system may disconnect the DCN network. A redundant 
NPU may improve the control system availability and thus 
also the DCN availability. 

• Easier maintenance. The redundant NPU solution may 
give a local configuration file backup. This simplifies the 
NPU repair procedures. 

PFU redundancy 

The power supply is a prerequisite for operation of the 
node. Redundant power inlet and distribution is vital in 
order to withstand one failure . 

The two power systems shall both be active sharing the 
load. A failure in the power system shall not result m any 
disturbance of traffic or control and management systems. 

• Double power inlet enables power redundancy in the 
site installation. 

• Redundant PFU remove all possible single point of 
failure in the unit 

Redundant PFU enables replacement of a PFU without any 
disturbance . 
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THE SPI BUS 

The equipment handling in TN uses the SPI bus in the node 
as a central component therefore some of the main SPI 
functionality is described here. 

The SPI bus is a low speed (approx. 1 Mbit) serial 
synchronous bus that is mandatory on all TN boards. The bus 
is controlled by . the NPU. It is a single master bus over 
which the NPU may execute a set of functions towards the 
PIUs. These functions are: 

• Place the board in cold and warm reset, 

• Read an onboard EEPROM containing information about 
the board. 

• Set alarm thresholds for the excessive and high 
temperature alarms . 

• Control the LEDs (yellow and red) on the PIU front. 

• Enable/disable: 2BPI, 4BPI, PtP-BPI interfaces, 
programming bus (PCI), and interrupts. 

Over the SPI interface the NPU. will be notified of the 
following: 

• Temperature threshold crossing. 

• PIU Power failure. 

• PFU Input power failure. 

• BR activation 

• Board insertion/power-up 

• PCI FPGA loading completion/ failure 

• PCI bus transaction failure. 

• pci capability (does the board have it or not) 

• Fan failure. 

• Application dependant interrupts (fan failure..) 



48 



The BNS will at start-up pass on to the applications the 
information found on the APUs SPI block. I.e.: the BNS will 
receive the temperature thresholds and will need to check 
them for validity, if incorrect change them to default 
values. The BNS will need to handle the NPU and PFU in a 
similar manner. 

The SPI interrupts will result in a trap to the ANS. The 
ANS may in addition read and write to the SPI functions. 
This may serve" as a means for a very low speed 
communication between the ANS and the APU (use of APORT) . 

The ANS can give the APU access to the SPI EEPROM by 
enabling bypass. This functionality is intended to be used 
for the redundant NPU solution. It may cause problems for 
the BN if this function is used by an application as the 
NPU looses the EEPROM access. 

START AND RESTARTS 

The node has the following types of restarts: 

0 NODE WARM RESTART 

1 NODE COLD RESTART 

2 NPU COLD RESTART 

3 APU COLD RESTART 

4 APU WARM RESTART 

During a restart the hardware within the scope of the 
restart will be tested. 

All restarts shall be logged in the "error log" . The reason 
for the restart shall be logged. 

Each restart may be triggered by different conditions and 
behaves differently. 

Restarts may be used for repair. A self -test that fails in 
a warm restart shall never result in a cold restart. This 
would lead to a situation where a control system failure 
could result in a traffic disturbance. There are one 
exceptions PCI access to the ASIC will lead to a cold 
repair . 
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A restart that affects the NPU (node warm/ cold or NPU cold 
restart) shall not change the state of any LBDs on any 
other boards. An APU with a service LED on (in the board 
removal interval) shall not have the LED turned off by an 
NPU restart. The board removal interval is likely to become 
longer but the state of the LEDs shall not change. 

• A restart that affects the NPU (node warm/cold or NPU cold 
restart) shall give a PCI reset. Thus if the NPU for some 
reason is reset then all APUs connected to the PCI bus will 
be disconnected from it. The PCI reset shall be given both 
before and after the NPU executes the restart. 

The node warm/cold and NPU cold restart restores the 
configuration file. 

EOUIPEMENT INSTALLATION AND REPAIR 
GENERAL 

Main procedure: 

It will be possible to request a board repair / removal by 
pressing the board removal switch (BR) on the front of the 
board. This disables traffic related alarms from the APU. 

The yellow LED on the board will be lit. when the board can 
be removed. The board is now placed in cold reset. 

The LED will stay lit for a period of x 2 seconds, (board 
removal interval /timer) . During this time the board may be 
safely removed. 

If an APU is removed it may be replaced during an interval 
of x 6 min (board replacement interval /timer) . If a new 
board of the same type is inserted into the same slot 
during this interval it will be configured as the previous 
board and will be taken into service automatically. 

The procedure for removing a board shall thus be : 

• Press the BR on the front. 

• When the yellow LED is lit, the board can be removed 
within x 2 sec and then if desired it could be. replaced 
within x 6 min. 

APU variants: 

• If the board is not removed during the board removal 
interval it will be taken into service at the expiration of 



50 



the board removal timer. This means that an APU warm 
restart is performed in order to take the unit into service 
again. Note that pressing the BR without removing the board 
is the same as cold starting the board, 

• If the board is replaced by a board of a different 
type than the one before it will result in a loss of the 
previous board's configuration. 

NPU variants: • 

• During the board removal interval the NPU does not 
have a HW warm reset signal asserted, but it is in a 
passive equivalent state. 

• When the NPU enters the board removal interval it will 
execute a PCI reset. This is done so as to ensure that if 
the NPU is replaced the NPU cold restart will be done 
without a lot of PCI bus activity. It is also done to 
ensure that the link layer protection mechanisms are in 
operation during the NPU unavailability. If the APUs where 
placed in warm reset the MSP 1+1 of an LTU 155 board would 
become inactivated. 

• Note that pressing the NPU BR without removing the NPU 
is the same as a NPU cold restart. 

PFU variants 

TN NE can be installed with or without power redundancy. 
Loss of power redundancy result in the notifications 
described in 0. 

If administrative status is set to *In Service' for all PFU 
(default) , the system is configured with power redundancy. 
In order to make this possible , the PFU modules has to be 
presented in the entity MIB even if only one PFU is 
installed.. 

FAU variants 

TN NE can be installed with or withput FAN unit . 

If administrative status for FAU is set to *In Service' 
(default), the system is configured with FAN unit. 
In order to make this possible the FAU module has to be 
presented in the entity MIB even if no FAU is installed. 

More details: 
BNS-ANS interaction: 
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When the BR in the front of the board is pressed, the BNS 
will inform the application (ANS) that the board should be 
taken out of service. 

When the application is ready, it will report to the 
platform that the board can now be removed. The BN will 
then deallocate the PCI device drivers for the board and 
light the board's yellow LED. The BNS shall then place the 
APU in cold reset so as to avoid signals from a board which 
is now unavailable to the ANS. 

Configuration: 

Note that the Running Configuration of a board under repair 
will be lost if: 

• The node powers down. 

• The node/NPU restarts. 

• The board is not replaced within the board repair 
interval . 

• Another type of board is inserted in the slot . 

When the board repair timer expires the board will be 
removed from running configuration and running 
configuration will be saved in the start-up configuration, 
i.e. the board can no longer be replaced without loss of 
the configuration. 

If the save timer is running when the board removal timer 
expires then the configuration file save will not be 
executed . 

BPI handling: 

The applications are responsible for the BPI handling. The 
BPI interfaces can be enabled by the applications if 
required. The BPI bus shall be used by the ANS as follows: 

• If an ANS has 2 boards connected to the 2BPI it may be 
enabled. If the application with an enabled 2BPI bus has 
less than two .boards on the bus it shall be disabled at the 
expiration of the board removal timer. 

• If an ANS has at least 3 boards connected to the 4BPI 
it may be enabled. If the application with an enabled 4BPI 
bus has less than two boards on the bus it shall be 
disabled at the expiration of the board removal timer. 
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• PtP BPI shall be disabled. 

The BPI busses are disabled as a consequence of a node or 
APU cold reset. 

TKTSTALLATION 

The following use cases require the operator to be present 
at site and to set the node in so-called node or NPU 
installation mode: 

1 Installation of a new node (Node installation) . The 
node doesn't have DCN links up and/or DCN 
configuration is wrong. I.e. the node is not 
accessible from a remote management site. 

2 Change forgotten password (Node installation) . 
Changing the -passwords without the old passwords 
should not be possible remotely. 

3 Fallback to old NPU software revision (Node 
installation) . This is an emergency use case only 
applied in case a software upgrade prevents any other 
up/downgrades . 

4 Repair of the NPU( NPU Installation) . The new NPU, 
that replaced the defect one, has a different 
configuration than the previous one . I.e. the 
configuration file would cause traffic disturbance 
and the node is. not accessible from a remote 
management site. 

There are two ways to enter node installation mode: 

• through pressing the BR button after node power-up 
(Use cases 1 to 3 above) . During this period the red and 
yellow LED on the NPU are on. 

• in case there is no configuration file present at 
restart. 

Node installation mode has priority over NPU installation 
mode. That is to say that if a condition for node 
installation mode occurs, even when NPU installation mode 
was active, the former mode will be entered. 

As there are four ways to enter NPU installation mode: 

• Pressing the BR in. the installation mode entry- 
interval after NPU power-up (Use case 4) . During this 
period the red and yellow LED on the NPU are on. 
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• ' There is no configuration start-up file present on the 
NPU (Use case 4) . 

• The software on the NPU doesn't match the System 
Release described in the configuration file and the node 
fails to upgrade. 

• There is incompatibility between a SR (Software 
Release) and the Backplane type (Use case 4) . 

Both installation modes can always be left by pressing the 
BR. A automatic save of the running configuration to the 
start-up configuration is always performed. 

LCT shall always be directly connected whilst a NPU or a 
node is in installation mode. 

Special behaviour of the node in both installation modes: 

• The node has a default first IP address. 

• A DHCP server is running that provides the LCT with a 
second IP address. 

• Default passwords are valid 

• IP router function is disabled 

• Operational status of the node shall be set to 
operational status "reduced service" and node equipment 
status w installation mode" and the yellow LED on the NPU 
shall be flashing (1 Hz) . 

• No 'save' time-out and manual 'save' not possible 
through the LCT. 

• IP-address of the FTP as specified in the MIBs is 
ignored and the second IP address is always used. 

• . FTP user and password are default, i.e. 'anonymous' . 

Each of the 4 uses cases that cause the node into 
installation mode are described in the next sections. 

Install node 

For the installation of a new node the operator arrives 
with the equipment at the site and has a goal to get the 
node connected to the DCN after which configuration of the 
node can be performed remotely as well as locally. The use 
case is illustrated in Figure . 
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After the AMM is equipped with the necessary PIUs the 
operator will turn on the power. In order to enter 
installation mode he will press the BR as described in the 
previous section . 

Since the configuration stored on the NPU may be unknown 
the operator is offered to delete the configuration, if one 
exists and return to factory settings. This means that the 
operator will have to perform a software upgrade in order 
to get the SRDF in the node . 

In the case where a node is installed traff ical disturbance 
is not an issue. A node power-up followed by an 
installation mode entry can therefore do a hardware scan to 
detect all APUs . The NE can then enable MSM/LCT access to 
the MCR application. 

What is important first is to establish DCN connection of 
the TN NE. The TN NE is connected to the IPv4 based DCN 
through either PPP links running over PDH/SDH/MCR links or 
Ethernet. The SDH STM-1 links have a default capacity PPP 
link on both the RS and the MS layer, no configuration is 
needed for that. For DCN over El and MCR configuration is 
needed. In the DCN over El case a PPP link needs to be set- 
up over an El . 

For MCR however frequencies have to be configured and 
antennas need to be aligned on both side of a hop. The 
latter requires installation personnel to climb in the 
mast, which due to logistics needs to be performed directly 
after hardware installation. For the MCR set-up the MSM 
must be launched. After MCR set-up is performed minimally 
required DCN, security, and Software upgrade set-up can be 
either configured through the download of a configuration 
file or manually. 

The configuration file indicated in the automatic set-up is 
appended to the running configuration in order to keep the 
previous MCR set-up. 

In both automatic set-up and manual set-up the operator is 
informed on the progress of the software upgrade. Complete 
new NPU PIUs from factory have a configuration file with 
correct SRDF info present. So here no software upgrade is 
needed . 

After the set-up the inventory data and DCN parameters are 
shown to the operator, who will exit the installation mode 
through a command via the LCT or by pressing the BR. 
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The node will perform a save of the configuration and enter 
normal operat ion . 



Figure 43 Install new node 
Repair NPU 

In case a NPU is defect, the operator can replace the NPU 
without disturbing traffic, except for traffic on. the NPU. 
For this purpose he has to be on site with a configuration 
file of the defect NPU* This configuration file can be 
obtained from a remote FTP server where the node has stored 
its configuration before. Or he can get it from the defect 
NPU in case this is still possible. 

Since the node will be in installation mode while 
downloading the configuration file, i.e. has the first IP 
address, the operator has to move the old configuration 
file from the directory named by the IP address of the. old 
NPU to the directory named by the first IP address. 

The NPU repair use case is illustrated in Figure . After 
the old NPU is removed and the new one is plugged in, the 
operator has to press the BR to enter installation mode. 

If he fails to do this the NPU will start-up normally and 
traffic can be disturbed due to an inconsistent start-up 
configuration file or in case no configuration file is 
present the NPU installation mode will be entered. Wrong 
NPU Software will automatically lead to entering the NPU 
installation mode. 

Since traffic is not to be disturbed the configuration file 
is not loaded nor. is a hardware scan performed. 

Since the username and password for the FTP server are set 
to default the user is asked to enter the username and 
password he wants to use. This prevents the operator of 
having to define a new 1 anonymous' user on the FTP server. 
After the operator has specified the name of the 
configuration file the node will fetch the file from the 
FTP server on the locally connected LCT laptop. The SNMP 
object xfConfigStatus is used to check if the transfer was 
successful . 

After that the installation mode is left and the node is 
warm restarted . Upon start-up the node will, if necessary 
automatically update the software according to the 
downloaded configuration file. 
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Figure 44 Repair NPU 
Change forgotten password 

If the operator has forgotten the password for a specific 
node he will have to go to the site and perform a node cold 
restart, i.e. power-up, and enter installation mode. This 
will lead to traffic disturbance. 

This operation is not possible in NPU installation mode 
since in NPU repair no hardware scan is performed and 
saving the running configuration (with the new passwords) 
would lead to an incomplete start-up configuration file. 

The node will perform a hardware scan and load the start-up 
configuration file. Subsequently the operator can change 
the passwords and leave installation mode. 

The use case is illustrated in Figure 45. 



Figure 45 Change forgotten password 
Emergency fallback NPU 

This alternative is used when the user wants to force a NPU 
SW rollback to the previous SW installation. This 
alternative shall only be used if a SW upgrade has been 
done to a SW version, which in turn has a fault in the SW 
upgrade that prevents further upgrades. 

The use case is illustrated in Figure 46 . 



Figure 46 Emergency fallback NPU 
REPLACE A NODE 

It will be possible to replace a complete node.. The 
configuration file must then be uploaded from the old and 
placed in the new node. 

Hardware of the new node must match the old one exactly. 
Only APUs placed in the same location will be able to get 
the previous configuration from the configuration file. 
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PEMOVE A BOARD 

Please note that if the procedure for removing of board is 
not followed, the node will do a warm restart. 

The procedure for board removal is as follows: 

5 

Figure 47 Removal of board (for information only.) 

If the board is not removed from the slot within a default 
period of time after the yellow LED has lit, the remove 
board request will time out and the board will be actxvated 
io with the running configuration. 

ADD BOARD TO EXISTING NODE 

The BN will inform' the application about the new APUs . The 
APU shall be given a default configuration. 

For a new inserted board notifications are only enabled for 
is board related notifications, not traffic related 
notifications. 

REPAIR A BOARD 

The node will hold the running configuration for a board 
for t 6 minutes after this the board has been removed from 
20 the slot. This includes all alarms will stay active until 
either the board is completely removed or the new board 
clears the alarms. 

The installation personal then has x 6 minutes to replace 
the board with another of the sarnie type . 

25 When the new board is entered the running configuration 
will be restored to the board. It is also possible that a 
hew ADS will be needed. SW upgrade can then be carried out 
from a file server or from the LCT. 

PWPAIR PFO 

so Non- redundant configuration 

in order to handle the case where only one PFU is fitted, 
and it is to be replaced, a special procedures is. 
implemented. 
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• Press the BR on the PFU. 

The NPU notifies the EM and lights the yellow LED. 
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• Remove the power and fan cable. 

• Replace the PFU. 

• Re- connect the power and fan cable. 
The node does a power -up. 

Redundant PFU configuration . 

If the node is equipped with redundant PFUs then a PFU 
repair can be done without taking the node down. 

Note: Fan alarms are not suppressed. 



REPAIR FAN 

No repair procedure is needed for the fan. The NMS is 
notified when the fan is removed / inserted. 

The replacement of the fan however needs to be quite fast, 
as the node will otherwise shut down due to excessive 
temperature . 

REPROGRAM PCI FPGA 

The TN NE has been prepared for PCI FPGA reprogramming . The 
PCI bus has a programming bus associated with it. This bus 
is a serial bus that may be used by the NPU to reprogram 
the PCI FPGAs on all the PIUs in the node. This bus is 
included as an emergency backup if the PCI FPGAs must be 
corrected after shipment. 

In order to utilise the programming bus the SW to handle it 
must be developed as this is not within the current scope 
of the system. 
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INVENTORY HANDLING 

When a new board is entered into the node, the board shall 
be activated and brought into service. A notification will 
be sent to the management system if a new board is 
detected . 

Activation of a board implies: 

• Activation of DCN channels 

• Generation of entity MIB's 

• Software upgrade if needed. 
MANAGEMENT 

Operational status 

Operational status in TN is supported on the node, 
replaceable units and on interfaces (ifTable) . This chapter 
describes the equipment (node and replaceable units) 
operational status. An equipment failure is the cause for 
an update of the operational status. The relation between 
equipment status severity and operational status is : 



Operational status 


Equipment alarm * 
severity 


In service 


clear/warning 


Reduced Service 


minor /major 


Out of service 


critical 



Operational status (Replaceable unit) : 
Replaceable units in TN are all boards (PIUs) and the fan. 



60 



In service: This status indicates that the unit is working 
properly. 

Reduced Service: This status indicates that normally 
supported traffic functionality is available but that the 
management functionality is reduced. (Due to minor alarms 
like for example high temperature) . 

Out of service: This indicates that the unit is not in 
operation, i.e. a traffic disturbing failure has occurred. 
When a PIU is out of service it is in the cold reset state. 
For PFU and FAU this state is not traffic related but 
indicates either non-presence (administrative state=out of 
service or a critical defect in the equipment status) . 

Operational status (Node) : 

In service: This status indicates that the node is working 
properly. 

Reduced Service: This status indicates that the traffic 
functionality in the backplane is available but that the 
management functionality (result of a minor equipment 
alarm) or a redundant function in the node is 
reduced/unavailable for which, a further reduction will have 
impact on traffic. (result of a ma j or equipment alarm). 

Out of service * This indicates that the node is not able 
perform the traffic function properly. 
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Equipment status 

Equipment status in TN is supported on the node and 
replaceable units. This status gives more detailed 
information as background to the operational status. The 
status of a replaceable unit is independent of that of the 
node and vice-versa. A change in the equipment status leads 
to an update of the operational status and a possible alarm 
notification with the equipment status as specific problem. 

Replaceable unit 

In addition to the operational status, the node supports 
equipment status on replaceable units. The equipment status 
may be one or more of the following: 



Equipment 
Status 


Severity 


Operational 
status 


In repair 


Board 

removed=critical 


Out of 
Service 


High 

temperature 


High=minor 


Reduced 
Service . 




Excessive=critical 


Out of 
Service 


Hardware 
error 


Control = minor 


Reduced 
Service 




TDM, Sync 
bus=maj or 


Reduced 
Service 
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• 


Power , 

Traf f ic=critical 

For Fan 
fault=critical 


Out of 
Service 

Out of 
Service 


Wrong 
software 


minor / critical 


Reduced 
Service / 
Out of 
Service 


Unsupported 
unit tvpe 

***** v * w i Jr 


critical 


Out of 
Service 


Wrong slot 


critical 


Out of. 
Service 



Node 

In addition to the operational status, the node supports 
equipment status on the node. The equipment status may b 
one or more the following values: 



Equipment 
Status 


Severity 


Operational 
status 


Power 

failure 

(redun) 


maj or 


Reduced 
Service 
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Traf f ical 


1 TDM/ sync 


Reduced 


system 


bus 


Service 


failure 


f ails=maj or 
2 or more 






TDM/ sync 
busses 

fail=critical 


Out of 
Service 


Control 


Redundant NPU 


Reduced 


system 


fails-minor 


Service | 


failure 


NPU 

fails=major 

PCI failure 
on all boards 
or SPI self- 
test 

f ailure=maj or 




Installation 


Node=minor 


Reduced 


mode 


NPU=major 
(missed 
redundancy . 
SNCP) 


•Service 



Administrative status 

It shail be possible to set the administrative status of 
the APUs as follows: 
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In Service: 

Out of service: The APU shall be held in cold reset. 
Alarms/event notifications are disabled. 

When an PIU' s administrative state is set 'out of service' 
the operational status will show: 'out of service' with no 
active alarms in the equipment status. This implies that 
for active alarms a 'clear' trap will be sent. 



A PFU or FAU that is set to 'out of service' is regarded as 
not present, i.e. no redundance in case of PFU, and not 
taken into account , for the node operational state. This to 
cover the case where a redundant PFU is wanted but it is 
detected faulty, i.e. not present. In that case the PFU is 
shown as administrative status 'in service' whilst 
operational status is out of service. At least one PFU in 
the node must have administrative status 'in service' . 

NODE CONFIGURATION HANDLING 

The node stores the configuration in one start-up 
configuration file. The file consists of ASCII command 
lines. 

Bach application has their chapter in the configuration 
file. The order of the application in the configuration 
file must represent the protocol layers . (SDH must come 
before El etc) . Each application is must specify its order 
in the start-up configuration file. 

The start-up configuration is. housed on the NPU, but the 
node is also able to up/down load start-up configuration 
from an FTP site. 
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When the node is configured from the "SNMP / WEB / Telnet" 
it will enter an un- saved state. Only running configuration 
is updated, i.e. running is not equal to start-up 
configuration anymore. Entering this state will start a x 6 
minutes timer, successive configurations will restart the 
timer. The running configuration is saved when a save 
command is received before the timer expires. If the timer 
expires the node will do an warm restart and revert to the 
latest start-up configuration. 

The node is also able to backup the start-up configuration 
file to an FTP server. This is done for each save command 
(not more frequently than x 6 minutes) . 



Figure 47+1 Save command handling 
Node generated save- command 

The node updates the start-up configuration in the case of 
board removal (after x 6 minutes timeout) . The node xs only 
updated in case of saved state. 

Configuration validation 

The configuration file shall include information about the 
AMM type for which the configuration is made. 

. Configuration files should not be exchanged between 
different backplane type. However in case e.g. an AMM 6p 
configuration file is used for a AMM 20p a kind of best 
effort will be done in configuring boards and node. 

If the file, contains configuration for an empty slot, that 
part of the configuration shall be discarded. 

If the file contains configuration for a- slot not matching 
the actual APU type, that part of the configuration shall 
be discarded . 
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FATTLT HAM nt.TWFt (EQTTIPMENT ERROR) 



GENERAL 

This chapter describes equipment errors in the node. The 
node handles single errors, double error is not handled. 

Faults shall be located to replaceable units. Faults that 
cannot be located to one replaceable unit shall result m a 
fault indication of all suspect units. 

The actions in this chapter are valid for units with 
administrative status set to 'In Service'. If a unit has 
administrative status set to 'Out of servxce' alarms shall 
be suppressed, and the unit is held in cold reset. 

General fault handling 

The figure below shows general principle of TN fault 
handling of hardware and software errors. 



Figure 48 Fault handling of hardware and software error. 

Fault handling includes handling of software and hardware 
faults. Other faults like temperature violation is not 
handled according to the state diagram above. 



Node error handling 

The figure 49 shows how the TN handles Node errors. 
Figure 49 TN Handling of node error. 

The Node fault mode is entered after 3 warm / cold fault 
restart within x 6 minutes. In this mode is the NPU ^ated 
from the APUs and fault information can be read on the LCT 
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APU error handling 

The figure 50 shows how the TN handles APU errors. 
Figure 50 TN Handling of APU/PIU errors. 

BOARD TEMPERATURE SUPERVISION 

The ANS shall set the temperature tolerance of the board 
(default 70/75 °C for high/ excessive) .. The BNS shall set 
the high and excessive temperature threshold as ordered by 
the ANS. The BNS shall accept and set values in the range 
50 - 95 °C. Incorrect values shall result in default values 
and the operation shall be logged in the sys log. 

BNS shall do the equivalent for the NPU and PFU boards . 
Detection 

Temperature will be measured on all boards in the node. Two 
levels of alarms shall be supported, excessive and high 
temperatures. The temperature sensor in the SPI BB will do 
this. 

Notification 

The PIU operational status shall be set to: 
minor/high temperature 
critical /high temperature 

Depending on which threshold is crossed. 

Note that this should not give any visual indications as 
the fault is likely to be either, a fan failure or a rise in 
the ambient temperature. 

Repair 

The high temperature threshold crossing shall lead to a 
power save mode on the APU (set the board in warm reset) . 
. The PIU shall after this be taken in service again if the 
temperature on the board is below the high temperature 
threshold continuously for a period of t 2 seconds. 
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Excessive temperature on the board shall result in a cold 
reset of the board. This second threshold level shall be 
handled by hardware and shall not be under software 
control. Board temperature reduction shall automatically 
s take the boards into service again. 

Excessive temperature on the PFU shall shut off power to 
the node. This function shall be latching, i.e. the power 
to the node shall be turned off before the power comes on 
again. 

10 Based, on high temperature the node will enter "node fault 
mode" (Isolated NPU, no access to other board) . The mode 
will be released when the high temperature indication is 
removed . 

FAN SUPERVISION 
is Detection 

The fan status is signalled on the SPI bus from the PFU. 
The signals only indicate OK/NOK. The individual fans are 
supervised and a failure is indicated if one fan faxls. 

A fan cable removal shall be detected as a fan failure. 
20 Identification 
SPI signal. 
Notification 

The fan operational status shall be set to: 
critical/hw error. 

25 Notification / alarm to NMS 

The fault LED on the fan shall be lit . 

Repair 

Manual replacement. 

The. fault may in addition result in temperature sUpervis 
30 handling. 



10 
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BOARD TYPE NOT SUPPORTED 
Detection 

The SPI indicates the NPU SW does not support a board type, 
Identification 

The SPI inventory information displays a board not 
supported by the NP SW. 

Notification 

The APU operational status shall be set 
to: critical /unsupported type. 

The APU fault LED shall be lit. 
Notification will be sent to the NMS. 
Repair 

None, The board will be held in cold reset. 



15 APU -POWER 
Detection 

The . basic node shall supervise that the APUs has a correct 
local power . This is supervised through the use of local 
power sensors. A power sensor fault will normally indicate 
20 that the APU has had a power dip. 

Identification 

SPI signal. 

Notification 

The power LED shall be turned off and if possible the fault 
2 5 LED shall be turned of during the time that the power is 
faulty. 

The APU operational status shall be set to: 
critical/hw error 

The error will be reported to the application/ and then to 
30 the EEM 
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Repair 

The board will be held in cold reset to power is back. 



PFU/ INPUT POWER SUPERVISION 
Detection 

The PFU will detect loss of incoming power or PFU defect 
with loss of incoming power as a consequence. This can o 
course only be detected when redundant power is used. 

Identification 

The PFU geographical address. 
Notification 

The NE operational status shall be set to: 
major /power failure 

The PFU operational status shall be set to: 
critical /hardware error 

Alarm will be sent to the EEM. 

Fault LED on PFU on and power LED on PFU off while the 
power is faulty. 

Repair 



None 
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T.TCn INDICATIONS 

The following LED indications shall be given on the PIUs 





Power OK 



Faulty unit, wrong slot, 
unsupported board . 



All 

except 

FAU 



Board may be removed 
(board removal interval) 
The FAU doesn't have 
yellow LED ' 



Power delivery failure 
red. pwr. 

unconnected power, 
cable 

- PFU failure (fuse, 
SCP. . ) - 



o o 



Power delivery failure 
no red. pwr. 

- unconnected power 
cable 

- PFU failure (fuse, 
SCP..) ' 



All 

except 

NPU 



o o 



Power up 



NPU 



NPU power up (IME 
interval) 



o 



NPU restart - during 
self-test • 



Node /NPU in installation 
mode ; ' 



TN NE failure (busses) 
Node fault mode. 
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1 • 


O 


0 | NPU BR 


• 


LED 


turned 


on 



(3 LED flashing 0.5 sec frequency 
(3 LED turned off 

Unchanged 

If BR Button is pressed on a faulty NPU the red led Will be 
turned off during the BPI, this to avoid conflict wxth the 
NPU power up signal. 
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Traffic Node: Software Upgrade 



Scope . - 

The document describes the software upgrade functionality 
offered by the TN. It specifies the functionality for 
upgrading one TN, not the functionality offered by 
external management to upgrade a whole network, like how to 
upgrade from network extremities back to the BSC or how to 
upgrade several TNs in parallel. 

Italic functionality is not part of Rl but will have 
postponed trouble reports written for them. 

General 

Software Upgrade is the common name for Remote Software 
Upgrade (RSU) and Local Software Upgrade (LSU) . Where RSU 
is defined as sowfatre upgraded from a remote FTP server 
whilst for LSU the local PC is used as FTP server . 

Software present on a TN is always according to a defined 
System Release (SR) . A SR is a package of all software that 
can be replaced by a SU of the software for: 

• TN Basic Node Software (BNS) in the NPS load module 
Application Node Software (ANS) in the NPS load module 

• Application. DP Software (ADS), i.e. APU with DPs 
The TN uses FTP for both RSU and LSU. 

A TN is always upgraded to a. SR. A SR contains always all 
BNS, ANS and ADS for that specific release. When performing 
a RSU or LSU, it is always from one SR to another. 

Futures 

Upgrade of AAS is for the future 
FTP server 

Software is transferred to the TN using the FTP both for 
• RSU as well as LSU. BNS has an FTP client that can download 
files from an FTP server. 
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The server is either on the DCN or in a locally attached 
PC, there is no difference between RSU and LSU except for 
speed* 

For RSU there must be an FTP- server somewhere on the DCN. 
Considerations must be taken to the DCN topology to avoid 
the RSU taking too long. Even if the network is okay from a 
traffic point of view, this might not be the case in the 
DCN point of view. There can be a need of several ftp- 
servers on the' same DCN. The files to be downloaded to the 
TN then have to be pre-loaded to the local ftp-servers. 

For LSU an FTP server has to be installed on the LCT PC. 

System Release structure 

An TN System Release (SR) consists of load modules for each 
type of processor software in the TN, and a System Release 
File (SRDF) describing the contents of the SR. 

The SR must be backward compatible at least two major 
customer releases. This to limit testing of software 
upgrade/downgrade, e.g when R6 is released it will have 
tested against R4 and R5 . 

It shall be possible to have different SRs running on 
different TNs within one TN network. 

The System Release Descriptio n File 

As the SRDF file name, and ftp- server location are given as 
MO's, see XF - SOFTWARE -MIB . Nodes can be given different ^ 
SRDF files and thereby run different Software, i.e. contain 
different load modules. 

SRDF is a CLI script file that is transcribed into the XF- 
SOFTWARE -MIB when downloaded and thus read-only. It is the 
only way to get information about load modules to the TN. 
The syntax, and semantics of the SRDF shall be revision 
controlled. It shall be possible to add comments to the 
SRDF. This can for example be used to indicate the APUs a 
certain DP software module belongs to. 

Each TN System Release will be represented by a directory 
on the ftp- server named by the product number and version 
of that release and contained by an tnj3ystem_release 
directory. All load module plus a srdf .tn file reside 
within one System Release directory. Product number and 
revision will denote each individual load module. For 
example : 

tn_system_release/ 
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file 



<name_of_release> directory 

srdf . tn SRDF-f ile 

CXP901584_1JR1A NPU load module file 

CXCR102004_1_R1B LTU 155 load module 

<n\omberjynyiU>_R2A load module file 

<number MMU RAU> R1A load module file 



Figure 51 example of TN System Release structure 
An optional header can include e.g. revision, hardware - 
version, and checksums, to enable BNS to control that it is 
the correct load module that has been loaded. Some of this 
information shall be included in the SRDF file as well. 

The TN Basic Node shall provide a RAM-disk of 6 MBytes for 
software upgrade of DP's. 

The XF- SOFTWARE -MIB 

All control and information regarding software upgrade will 
be represented by Managed Objects in the XF- SOFTWARE -MIB . 

For each TN two System Releases will be defined in the XF- 
SOFTWARE-MIB, one Active System Release and one Passive 
System Release. . For each System Release the overall 
product number and revision is presented in the XF- 
SOFTWARE-MIB as well as the product number and revision of 
each load module contained by the corresponding System 
Release . 

The active SR shows the current SR running on the TN and is. 
a reference for new boards as to what software should run 
on the board in order to be compatible with the rest of the 
node. 

The passive SR describes the previous SR the node was 
upgraded to whilst in normal operation. During the software 
upgrade process the passive SR will describe the software 
the TN is currently upgraded to. 

The XF - SOFTWARE -MIB Software shows the. product number and 
revision of current running software in the active memory 
bank for each APU and those for the software in both active 
and passive of the NPU 
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The Software Memory Banks 

Each APU/NPU with a DP contains two flash memory banks, an 
active and a passive one. The flashes are used to contain 
the current and previous software for the corresponding 
APU/NPU. The software in the active bank is the one 
running. The one in the passive bank is used to perform a 
fallback to a previous System Release for that APU/NPU 
whilst a new software upgrade is being tested. 

The software in the passive bank can also be used to 
perform a manual switch to previous software for the NPU. 
This is not a normal situation procedure and can only be 
performed in installation mode. It should only be used in 
emergencies and is against the policy that a node only runs 
a tested SR. 

The software modules described in the active SR will always 
be present in the active memory bank of the respective NPU 
or APUs . 

The passive memory bank can contain the following software: 

1) The load module as described in passive SR. In this 
case the load module in the passive SR is different than 
the one in the active SR. In case of a fallback the APU/NPU 
will switch to the passive memory bank if it is a part of 
the passive SR. 

2) The load module does not correspond with either active 
nor passive release in case: 

a) The load module had the same release in the last two 
upgrades. In this case a fallback will not lead to a memory 
bank switch. 

b) The APU was inserted into the system after a software 
upgrade of the TN as a whole. In this case, automatic • 
software upgrade of this single APU is performed as 
described, in 0. In this case fallback is not an option as 
can be read in 0. 

The various cases are illustrated in Figure 52 below. 



Figure 52 Illustration of the various contents of. the 
APU/NPU memory banks 
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Upgrade of a node to a System Release 
Normal procedure 

The main software upgrade sequence is the one performed 
remote or local, i.e. from an EM or EEM, for a whole node. 
Special cases are described in the following sections. 

Before starting a .software upgrade the FTP server location 
(IP address) and username/password must be specified. 

The software upgrade sequence is started with the EM/LCT 
changing objects in the TN describing the product number 
and revision of the SR to upgrade to. Once the EM/EEM 
starts the upgrade process the TN will ask for the SRDF- 
file via its FTP client. on location: 

The tn_system_jrelease is the directory under which all SRs 
for TN are available. This is not configurable by the 
EM/LCT: 

When the SRDF-file has been downloaded, evaluated and 
represented in the XF - SOFTWARE -MIB, the TN will download 
the necessary load modules via its FTP client to. its RAM- 
Disk. 

For the software upgrade process to proceed fast enough, 
the FTP server is assumed to have a limited number of 
client connections open at a given time. So in case of an 
upgrade of a whole network, few high-speed connections are 
preferred over many low-speed connections. 

The whole process is illustrated in Figure 53 below. 

A load module downloaded to the RAM-disk on the NPU must be 
marked read-only until the respective controlling program, 
i.e. ANS, has finished the download to the target FLASH. 

The new software is now marked to be used after a warm- 
restart of the TN and the EM/LCT . orders a warm- restart 
directly or scheduled at a given date and time. 

The warm- restart at a specified date and time will be used 
if many nodes are upgraded and have to be restarted at 
approximate the same time to have the OSPF routing tables 
update as soon as possible. 

Marking the new version for switching will happen at the 
given date and time just befpre the warm-restart. 
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During the warm- restart of the TN all ANS will check their 
APU's (by self -tests) to see whether the correct ADS is 
running. APUs that are in cold reset are not tested in the 
test run. If all was OK, the EM/EEM-user will be notified 
about this. The EM/EEM-user shall then have to commit, 
within a certain time, the new System Release. If no commit 
is received by the TN in time a fallback will be performed, 
i.e. it will mark the old revision as active and perform a 
warm-restart again. 

The operator can also indicate a so-called node initiated 
commit. In that case the operator doesn't have to commit 
the new software, but the node checks whether it still has 
DCN connectivity. In case DCN connectivity was lost as a 
result of the software upgrade a fall -back will be 
performed. 

A node initiated commit will be default when executing a 
scheduled SU. 

The progress of the LSU/RSU process shall be available 
through status. MO' s in the XP - SOFTWARE -MIB . 



Figure 53 The Software Upgrade process illustrated 
Failure of upgrade of APUs as part of a system realease 

In order to have a consistent and tested SR running on the 
TN APUs that fail to upgrade as part of a SR upgrade will 
be placed in warm reset in test phase and after a commit. 
This means that traffic will be undisturbed but that the 
APU is not longer under control of the NP software. 

Another attempt to upgrade the board will be made when the 
APU or TN is warm/cold restarted. 

Hot swap during upgrade 

A board inserted during the software upgrade process will 
be checked/upgraded according to the active SR. It will not 
be upgraded as part f the upgrade to the new System release 
. but as part of the test phase of the new system release. 

No load module for APU 

If no load module is. present in. the new SR for an APU type, 
these APUs will be set in warm reset and upgrade to the new 
SR will continue? 
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Equi pment error during software upgrade 

Any form for equipment error during software upgrade will 
lead to abortion of the software upgrade process, which 
will be notified to the EM/LCT-user . 

If an APU is in the cold/warm reset state due to e.g. 
"hardware error" , w administrative state down" or 
"excessive temperature" it shall still be possible to 
perform a software upgrade of a SR. The specific board will 
not be upgraded." But the software upgrade will fail if the 
equipment status on an APU changes during the upgrade. 

SR download failures 

The following failures can occur during download of SRDF 
and load modules for a SR: 

• FTP server/DCN down; the access to the FTP client 
times out 

• Wrong username/password 

• Requested directory/ file not found on FTP server 

• Corrupted load module 

All these cases 3 attempts will be undertaken. Failure 
after 3 attempts leads to abortion of the software upgrade 
(in case of SRDF) or placing the corresponding APUs in warm 
reset as stated in 0. 

Fallback 

After a switch to the new SR, i.e.. an TN warm- restart , the 
TN goes into a test phase. The test phase will end when the 
COMMIT order is received from external management. After 
the COMMIT order is received, there will be no fallback 
possible. Situations that will initiate a fallback are: 

• COMMIT order not received, within x 6 minutes after the 
switch 

• Warm/cold node restart during the test phase. 

If one of the situations mentioned above occurs, then the 
NPU will switch SR (fallback) . Then the APUs will be 
ordered to switch software according to the previous SR. 
Manual/ forced fallback is not supported in the TN. 
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su not finished before scheduled time 

In case the downloading of all required load modules is not 
finished x 7 minutes before the scheduled time, the whole SU 
will be aborted and the operator will be notified. 



Software upgrade of sin gle APUs 
Normal procedure 

In order to have a consistent SR running on the TN APUs 
that are restarted have to have the correct software in 
respect to the SR. A restart of a APU can be caused by: 

• The operator who initiates a cold restart of the APU 

• An APU being inserted 

• A cold/warm restart of the node. Only APUs in warm 
reset will then be restarted. 

The principal of 'plug and play' shall apply in these 
cases, which means that the restarted APU shall be 
automatically upgraded: 

• Check out whether the software revision according to 
the active SR is already on the APU (passive or active 
mememry bank) . 

• If not, download the corresponding load module and 
then switch software on that board. 

• The board will then run software according to the 
active SR, but the software in the passive memory bank 
might not be according to the passive SR. 

BNS does not update both banks. Manual/ forced fallback is 
not supported. in TN. 

When no boards are inserted since last software upgrade a 
fallback of the whole node could be achieved by downgrading 
the software. In that case only the SRDF has to be 
downloaded, since the previous software is still n the 
passive memory banks. 

The ANS shall be able to communicate with older ADS when it 
comes to SU. 



Figure 54 Su of a single APU due to a APU restart 
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Figure 55 Hot Swap Software Upgrade 
Mew board type inserted 

In case a new board type is inserted for which there is no 
ANS on the NPU. The APU will be marked not-supported and 
placed in cold reset. 

Failure of upgrade of APUs 

In case SU for a single cold restarted APU fails, three 
attempts will be made before the APU will be placed in cold 
reset . 

in case SU for a single warm restarted APU fails, three 
attempts will be made before the APU will be placed in warm 
reset . 

Load module download failures 

The following failures can occur during download of a load 
module for a DP: 

• FTP server/DCN down; the access to the FTP client times 
out 

• Wrong username/pas sword 

• . Requested directory/file not found on FTP server 

• Corrupted load module 

For all these cases section 0 applies. 

. New system release already in p assive memory bank 

In case the new DP is already in the passive memory bank of 
the. Then there is no need for downloading the load modules 
for that APU. 

Load module not, specified 

If a load module is not specified in the SRDF, there can be 
no upgrade of that APU. The APU will be placed in cold 
reset. ' 
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Fault during flash memory programming 

If an error occurs in the process of programming the flash 
the TN will be notified and the whole upgrade process is 
aborted. The equipment status (hardware status) of the 
faulty board will be set to hardware error (critical), i.e. 
Out of Service, this will light the red led on the APU. The 
ANS must handle Plash located on the APU. 

Special NPU cases 
Upgrade of non-TN boards 

If the NPU software does not handle the upgrade, e.g. in 
the MCR Linkl case, the NPU software will only be aware of 
the hardware through the equipment handling of the board. 

No SRDF available 

When no SR information in the configuration file is present 
on the NPU the node will enter NPU installation mode upon 
restart . . 

Incompatible software and AMM 

In case the active software is incompatible with the AMM or 
doesn't recognize the AMM, the node will go in NPU 
installation mode, upon restart . . 

Requirements to the configura tion file 

The SU configuration command saved in the conf iguration 
file must be backward compatible. 

Upgrade time 

. in this chapter an estimate is made for both LSU and RSU. 
RSU 

- .-in-order to estimate the total RSU time for a reference TN 
network topology as described in Feill Fant ikke 
referansekilden. and a structure as shown in Figure 56 the 
following characteristics are assumed: 

• 16 Mbytes in a SR 

• 512 kBits/s DCN in the SDH ring 

• 128 kBits/s DCN on the radio links 

• no IP congestion and overhead 

• 5 TNs in the STM-1 ring 

• four MCR sub-branches per. TN in the STM-1 ring 

• a depth of MCR sub -branch of 3 
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Figure 56 TN reference network topology 



A typical RSU time can be calculated. It will take 16*8 
[Mbit] /0,512 .[Mbit/s] = 250 seconds in the STM-1 ring per 
TN and 16*8 [Mbit] /0,12s [Mbit/s] = 1000 seconds in the 
MCR branch. 

A MCR branch can have four (512/128) sub-branches without 
adding to the download time, i.e. software to a TN in each 
of the branches can be performed in parallel. 

In the MCR branch, however, downloads must be serialised at 
128 Kbits/second. 

For a reference network with 5 TN in the STM-1 ring and 
four MCR sub-branches with a depth of three, i.e a TN sub- 
network of 60 NEs, the download time is: 

5 [SDH NE] *250 [sec/SDHNE] +5 [SDH NE] *3 [TN/Branch] 
*1000[sec] =16250 sec=4.5 hours 

Each SDH NE plus its 4 branch, depth 3 sub-network RSU will 
require 3250 seconds, about one hour, longer. 

Every 4 extra branches for a SDH NE will require 1000 
seconds per TN in a branch. Say roughly one hour, assuming 
a depth of 3 to 4, per 14 TNs. 

The actual erasing/programming of the flash memories adds 
to these times. Estimated programming times of flash are 
14 seconds /Mbytes to erase and 6 seconds /Mbytes to program. 
Which adds to 320 seconds for 16Mbyte. 

However we cannot just add the download time and flash 
programming time, because a smart system will probably use 
the erase time on a node to download etc. 

In requirement 47A a maximum time of 8 hours is required, 
which is fulfilled for the assumed reference network when 
programming and downloading are two parallel processes. 
However an extra hour is required for each new branch, of 
depth 3 to 4. Which means that requirements will be 
fulfilled for TN sub-networks with up to 

8hrs=28800 sec/ (3250 sec/ (1+3*4) NEs=115 TNs. 
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The maximum time for RSU of an TN from EM is t 8 minutes. 
(Requirement 48A according to — ) 

LSU 

For LSU the sum is much simpler: LCT on the site-LAN with a 
5 speed of lOMbit/s, but 3Mbit/s available to the LCT, will 
aprox. require 16 [MByte] * 8 [bit/Byte] /3 [Mbit/s] =42 
seconds. Note that.no message! overhead is assumed. 

For LSU the erase time per Mbyte flash memory is longer 
than the download time but this can be done in parallel for 

10 all passive memory banks in all APUs, whilst down loading 
modules. The biggest single memory bank will be on the NPU 
(8 Mbytes) which will take 112 seconds to erase. 
Programming will then take 16*6seconds=96 seconds. Erase 
plus program time is then around 208 second as a resulting 

is LSU time. 

The maximum time for LSU from LCT is t 7 minutes. 
(Requirement 46B ) 

Note that while in the foregoing, there has been provided a 
detailed description of particular embodiments of the 
20 present invention, it is to be understood that equivalents 
are to be included within the scope of the invention as 
claimed. 
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AMM 
ANS 
ANS 
APU 
ASH 



Application Module Magazine 



Application Node Software 



Application NPU SW = AIM + ADD. 



Application Plug- in Unit 



Application Specific Hardware 



AWEB Application WEB 



BB 



Building Block 



BERT Bit Error Rate Test (er) 



BGP 



Border Gateway Protocol 




BRP 



Board RePair 



ASIC Functional unit handling Digital cross connect. 
ASIC ASIC handling the traffic part of ASIC. 



CLI 



Command Line Interface 



cPCI Compact PCI 



t 
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DCN Data Communication Network 

DHCP Dynamic Host Configuration Protocol 

DP Device Processor 

El 2 Mbit/s PDH 

EEM Embedded Element Manager 

EM Element Manager 

FCC Federal Communications Commission 

FD Functional Description 

FM Fault Management 

FPGA Field programmable gates array. 

FTP File transfer Protocol 

FTP . File Transfer Protocol 

GA Geographical Address 

GNU Unix- like operating system 

GPL GNU Public Libraries 

HCS High Capacity Switch 

HDSL High-speed Digital Subscriber Line 

HRAN Higher part of Radio Access Network 

HSU High capacity Switch Unit 
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HTML Hyper -Text Markup Language 



HTTP Hyper-Text Transfer Protocol 



HTTPS HTTP Secure 



HW 



Hardware 



I /o Input /Output 



IEC International Electrotechnical Commission 



IME 



Installation Mode Entry 



IP 



Internet Protocol 



IWD interWorking Description 



JTAG Joint Test Action Group 



LAN 



Local Area Network 



LCT 



Local Craft Terminal 



LIU 



Line Interface Unit 



LRAN Lower part of Radio Access Network 

LSU Local SW Upgrade 

LTU APU hosting 16 Els 

16x2 

MCR . Medium Capacity Radio 



MIB Management Information Base 
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Element Manager for the TRAFFIC NODE product family 



Manager 



TN 



TN Network Element 



TN BN TN-Basic Node 



TN BNH TN-Basic Node Hardware 



TN BNS TN-Basic Node Software 



TN NE TN Net Element ( TN Node) 



TN-EM TN Element Manager - see Manager. 



MSM 



TRAFFIC NODE Service Manger 



MSP Multiplexer Section Protection 



NEM 



Network Element Manager 



NETMAN TRAFFIC NODE Management System 




NPS 



Mode Processor Software 



NPU 



Node Processor Unit 



NPU Node Processor Unit (the PBA) 



NTP 
O&M 



Network Time Protocol 
Operations and Maintenance 
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OSPF Open Shortest Path First 

OSPF Open Shortest Route First 

P-BIST Production Built In Self-test 

PCI Peripheral Component Interconnect 

PCI-SIG Peripheral Component Interconnect Special Interest 
Group 

PDH Pie sio- synchronous Digital Hierarchy 

PFU Power Filter Unit 

PFU Power Filter Unit 

PHP Private Home Page 

PICMG PCI Industrial Computer Manufacturers Group 

PID Process Identification 

PIU Plug- In Unit 

PM Performance Management 

PPP point -to- Point Protocol 

PRBS Pseudo-Random Binary Signal 

PtP Point to Point links connecting APU and HSU slots 

ram Random Access Memory 

RSU Remote SW Upgrade 
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SCP 



Short Circuit Protection 



SDH Synchronous Digital Hierarchy 



SDH TM SDH Terminal Multiplexer 



SDRAM Synchronous Dynamic Random Access Memory 



SNCP Sub-Network Connection Protection 



SNMP Simple Network Management Protocol 




SRDF System Release Description File 



SSL 



Secure Socket Layer 



STM-1 Synchronous Transport Module -1 



SW Software 



TCP Transport Control Protocol 



TDM Time Division Multiplex 



TDM Time Division Multiplexing 



UDP User Datagram Protocol 



URL 



Uniform Resource Locator 



XF-EM 



XF- Element Manager and LCT 



XF-NE XF Node 
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TERMINOLOGY 

(Sorted by subject.) 
Application; 

Board specific SW and hardware (SDH-TM is an application) 
High Availability; 

Notation from cPCI standards characterising the ambition 
level of the system with respect to availability. In this 
document it mainly refers to the module in the basic node 
which is responsible for SW supervision and PCI config. 

Platform; 
Basic Node. 

Fault detection; 

The process of detecting that a part of the system has 
failed. 

Fault identification; 

The process of identifying which replaceable unit that has 
failed. . 

Fault notification; 

The process of notifying the operator of the fault. 
Fault repair; 

The process of taking corrective action as a response to a 
fault. 

Warm reset; 

This is a signal on all boards. When pulsed it takes the 
board through a warm reset (reset of the control and 
management logic) . While asserted the unit is in warm reset 
state. The PCI FPGA will be reloaded during warm reset. 

Cold reset; • 
This is a signal on all boards. When pulsed it takes the 
board through a cold reset (reset of all logic on the 
board) . While asserted the unit is in cold reset state. The 
cold reset can be monitored. 
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waVm restarts 

A restart of the control and management system. Traffic is 
not disturbed by this restart. The type of restart defines 
the scope of the restart, but it is always limited to the 
control and management parts. During the restart the 
hardware within the scope of the restart will be tested. 

Cold restart; 

A restart of the control and management - and the traff ical 
- system This type of restart will disable all traffic 
within the scope of the restart. The type of restart 
defines the scope of the restart. During the restart the 
hardware within the scope of the restart will be tested. 

Temperature definitions ; 



Temp . 



Excessive 


. ► 




■ 






Hiah 


Temp, 








r 





Excessive 
temp. 



High temp 
threshold 



Hiah temperature threshold; 

The threshold indicates when the thermal shutdown should 
start. The crossing of the threshold will give an SPI 
interrupt to the NPU. 

Excessive temperature threshold; 

The threshold indicates when critical temperature of the 
board has been reached. The crossing of the threshold will 
give a cold reset by HW and an SPI status indication to the 
NPU. 

Excessive temperature supervis ion hysteresis; 
The high and excessive temp thresholds determine this 
hysteresis. If the excessive temp threshold is crossed then 
the cold reset will not be turned off until the temp is 
below the high temperature threshold. 
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Hi gh temperature supervision "hysteresis" ; 

The high temperature supervision will make sure that the 

board has been in the normal temperature area continuously 

for at least t 2 seconds, before the warm reset is turned 

off. 

Normal temperature: 

In this area the boards are in normal operation. 
High temperature:- 

In this area the boards are held in warm reset. This is 
done in order to protect the system from damage. The 
shutdown also serves as a means for graceful degradation as 
the NP will deallocate the PCI resources and place the APU 
in warm reset thus avoiding any problem associated with an 
abrupt shutdown of the PCI bus. 

Excessive temperature : 

In this area the boards are held in cold reset. The S PI 
block (HW only) does this when the excessive temperature 
threshold is crossed. This is done in order to protect the 
system from damage. 

Running configuration: 

This is the active configuration of the TN node. See 
chapter 0 for more details. 

Start-up configuration: 

This is a configuration of the TN node saved into non- 
volatile memory, the running configuration is stored into 
the start-up configuration with the save command. Node and 
NPU restarts will revert from running to start-up 
configuration. 

Administrative Status: 

This is used by the management system, to set the desired 
states of the PIUs. It is a set of commands that sets the 
equipment in defined states. 

Operational Status: 

This information describes the status of the equipment. 
Management can read this. Operational status is split into 
status and the cause of the status. 

Board Removal Button (BR) : 

This is a switch located on the front of all boards. If it 
is pressed this is a request to take the board out of 
service (see service LED) . On The NPU this switch is. used 
to place the node and the NPU in installation mode. 
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flgWLce LED: 

This is a yellow LED indicating that the board can be taken 
out of the subrack without disturbing the node. The service 
LED on the NPU will also be lit during the period after a 
node or NPU power-up in which the board may be placed in 
installation mode. When the node is in installation mode 
the yellow LED on the NPU will flash. The term yellow LED 
and service LED is in this document equivalent. 

Power LED: 

This is a green LED indicating that the board is correctly 
powered. The term green LED and power LED is in this 
document equivalent. 

Fault LED: 

This is a red LED indicating that a replaceable unit needs 
repair handling. The NPU fault LED will be on during NPU 
restarts until the . NPU self -test has completed without 
faults. The APU will have fault LED default off. The NPU 
fault LED will flash to indicate node /bus faults. The term 
red LED and fault LED are in this document equivalent. 

Node Installation mode: 

This is a state where the TN may be given some basic 
parameters. The mode is used to enable access during 
installation or after failures. 

NPU Installation mode: 

This is a mode for repair of the NPU. The mode is used when 
a new NPU is installed in an existing node. 



Node Fault mode: 

The Node fault mode is entered after 3 warm / cold fault 
restart within x 6 minutes. In this mode is the NPU. isolated 
from the APUs and fault information can be read on the LCT. 

Board repair interval (BRP interval) 

This is the interval during which an APU and PFU may be 
replaced with an automatic inheritance of the configuration 
of the previous APU. 

Board repair timer (BRP timer) 

This timer defines the board repair interval. It has the 
value %b minutes . 

Board removal interval (BRM interval) 

This is the interval during which an APU may safely be 
removed from the subrack. A yellow LED on the PIU front 
indicates the interval. 
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Board removal timer (BRM timer) 

This timer defines the board removal interval. It has the 
value t 2 seconds . 

Save interval 

This is the interval after a configuration command to the 
NE in which the operator must perform a save command. 

Save timer . ■• . 

This timer defines the save interval. It has the value x s 

minutes. 

Installation mode entry i nterval (IME interval) 

This is the interval after a node or NPU power-up in whxch 

the node may be placed in installation mode. 

Installation mode entry timer (TME timer) 
This timer defines the Installation mode entry interval. 
The specific value of this timer will not be exact but it 
shall be minimum x 3 seconds (depends on boot time) . 
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